## What happened

Upgrading to 4.0.2+ silently breaks Voxtype for anyone using Voxtype's own evdev hotkey (`[hotkey] enabled = true` in `~/.config/voxtype/config.toml`).

`migrations/1787865477.sh` removes the user from the `input` group. Voxtype 1.0's hotkey listener reads `/dev/input/event*` directly, so it loses access. The daemon keeps running and looks completely healthy — it loads its model, reports `Listening for hotkey: RIGHTCTRL`, and the bar indicator behaves normally. The only sign of failure is a single line in the journal:

```
INFO  Model loaded, ready for voice input
INFO  Listening for hotkey: RIGHTCTRL (press to start/stop recording)
ERROR Hotkey listener error: No keyboard device found in /dev/input/
```

Pressing the hotkey does nothing. Nothing is shown to the user.

`voxtype setup check` names the cause directly:

```
Input:
  ⚠ User is not in 'input' group
       evdev hotkeys: unavailable
       Required only for evdev hotkey mode, not compositor keybindings
       To enable: sudo usermod -aG input $USER && logout
```

## Root cause

`migrations/1787865477.sh` (added in #9200) preserves `input` membership for exactly two opt-in features:

```bash
if id -nG "$USER" | grep -qw input; then
  if pacman -Qq xpadneo-dkms &>/dev/null || pacman -Qq ydotool &>/dev/null; then
    echo "Keeping $USER in the input group: controller or ydotool support is installed."
  else
    sudo gpasswd -d "$USER" input >/dev/null
```

Voxtype's evdev hotkey is a third such feature, and it isn't checked.

I want to be upfront that **Omarchy's shipped Voxtype configuration does not regress.** `default/voxtype/config.toml` sets `[hotkey] enabled = false` and `default/hypr/bindings/voxtype.lua` binds dictation through the compositor:

```lua
o.bind("SUPER + CTRL + X", "Toggle dictation", "voxtype record toggle")
o.bind("F9", "Start dictation (push-to-talk)", "voxtype record start")
```

Those paths need no `input` membership and still work. This only affects users who opted into Voxtype's built-in hotkey.

That opt-in is not an exotic configuration, though. It is the only way to use a bare modifier as the trigger, because a bare modifier cannot be bound in Hyprland — something Omarchy already documents in #7302 ("Note that voxtype push-to-talk can't be rebound to a bare modifier key"). Users who chose right Ctrl or a similar key have no compositor-side fallback to fall back to.

## Steps to reproduce

1. Install on Omarchy 4.0.0 or earlier, where every user was placed in `input` by default.
2. Install Voxtype and set it to use its own hotkey, e.g.:
   ```toml
   [hotkey]
   enabled = true
   key = "RIGHTCTRL"
   mode = "toggle"
   ```
   Confirm the hotkey works.
3. Run `omarchy update` to 4.0.2 or later, so `migrations/1787865477.sh` runs.
4. Log out and back in.
5. The hotkey no longer does anything. `journalctl --user -u voxtype` shows `No keyboard device found in /dev/input/`.

On my machine the migration marker is present at `~/.local/state/omarchy/migrations/1787865477.sh`, timestamped in the same update run that took `voxtype-bin` from 0.7.5 to 1.0.1.

## Suggested fix

Extend the preserve condition to cover users who have opted into Voxtype's evdev hotkey, mirroring the existing package checks — for example, keeping membership when `~/.config/voxtype/config.toml` has `[hotkey] enabled = true`. That keeps the security intent of #9200 intact: users on Omarchy's default compositor-binding setup still get the grant dropped, and only those who deliberately chose evdev keep it.

`test/shell.d/input-group-migration-test.sh` already has a `run_migration "<groups>" "<packages>"` harness that a case for this drops straight into.

Worth noting separately: fixing this migration only protects future upgrades. Anyone already affected has had the group removed, so restoring it for opted-in users would need a new migration.

## System details

| | |
|---|---|
| Omarchy | 4.0.3-1 (stable) |
| Kernel | 7.2.3-arch1-3 |
| CPU | AMD Ryzen 7 5825U with Radeon Graphics |
| GPU | AMD/ATI Barcelo (rev c1) |
| Hyprland | v0.56.2 |
| voxtype-bin | 1.0.1-1 |

`/dev/input/event*` are `root:input` mode `660`, so group membership is what gates access:

```
/dev/input/event0 root:input 660
```