## What happens

All ten `SUPER + code:N` (or `SUPER + SHIFT + code:N`) workspace bindings fire
in a single cascade instead of just the one that matches. The correct action
runs first, then ~180–290 ms later Hyprland walks the whole family in
registration order, so the window and the focus always end up on **workspace
10** regardless of which digit was pressed.

Captured from Hyprland's event socket, one press of `SUPER+SHIFT+5`:

```
529.529  createworkspace>>5
529.529  movewindow>>561e48343020,5     <- correct action
529.531  workspace>>5
529.713  movewindow>>561e48343020,1     <- cascade begins, 184 ms later
529.715  workspace>>1
529.717  movewindow>>561e48343020,2
529.718  movewindow>>561e48343020,3
...
529.730  createworkspace>>10
529.731  movewindow>>561e48343020,10
529.731  workspace>>10                  <- ends here, every time
```

The same happens to the `SUPER + code:N` family (`workspace>>1` … `>>10` with
no `movewindow`), so it is not specific to moving windows.

## Expected

Only the binding whose keycode matches should fire.

## Why it looks like a binding-registration problem

`hyprctl binds` reports the `code:`-based bindings with **no key and no
keycode**, while bindings declared with a key name keep theirs:

```
{'modmask': 64, 'key': 'L', 'keycode': 0, 'catch_all': False} | Toggle workspace layout
{'modmask': 64, 'key': 'K', 'keycode': 0, 'catch_all': False} | Keybindings
{'modmask': 64, 'key': '',  'keycode': 0, 'catch_all': False} | Switch to workspace 3
{'modmask': 65, 'key': '',  'keycode': 0, 'catch_all': False} | Move window to workspace 3
```

`default/hypr/bindings/tiling.lua` builds these as `"SUPER + code:" ..
(workspace + 9)`. With neither `key` nor `keycode` retained, the ten bindings
of a family are distinguishable only by `modmask`, which is identical across
all ten — which is exactly the shape needed for all of them to match one press.

Reproduced with two throwaway bindings registered through the same Lua API,
same modmask, different `code:` values: both came back as `key: ''`,
`keycode: 0`.

`o.bind` in `default/hypr/helpers.lua` is a thin pass-through to `hl.bind`, so
whatever drops the keycode is below it, in the Lua binding API rather than in
Omarchy's wrapper.

## Steps to reproduce

1. Focus any window.
2. Press `SUPER + SHIFT + <digit>`.
3. Watch `socat -u UNIX-CONNECT:$XDG_RUNTIME_DIR/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock -`

## Important caveat

I only see this when the keystrokes come from a **remote virtual keyboard**
(waynergy 0.0.17 injecting through `wlr-virtual-pointer`/`virtual-keyboard`
from a Windows Deskflow server), not from the laptop's own keyboard. It is
intermittent even then: 4 cascades out of 22 binding activations in one
session. Pressing Super *before* Shift makes it far less likely; pressing Shift
first is what usually triggers it.

So the trigger clearly involves how the events arrive, and I could not isolate
the second factor that normally supplies the discrimination. I am filing it
because the registration state above (`key: ''`, `keycode: 0`) looks wrong on
its own terms and is reproducible without any of the remote-keyboard setup —
if `code:` bindings are supposed to retain their keycode, that is a bug
regardless of what triggers the cascade.

I could not confirm whether the keycode is genuinely lost internally or merely
absent from `hyprctl binds` output: driving the matcher with `wtype` failed to
trigger even a named-key control binding, so that experiment was inconclusive.

## System

```
Omarchy:  4.0.1-1
Hyprland: 0.56.2
Kernel:   7.1.9-arch1-2
CPU:      Intel(R) N100
GPU:      Intel Alder Lake-N [UHD Graphics] [8086:46d1]
Session:  wayland / Hyprland
```