### System details

- Omarchy Quattro 4.0.1-1
- Hyprland 0.56.2
- libxkbcommon 1.13.2-1
- Intel Core i5-1035G1 / Intel Iris Plus Graphics G1 (Ice Lake)
- Keyboard layout: `es` (Spanish), reported by Hyprland as `active keymap: Spanish`

### What's wrong?

The `SUPER K` keybindings menu renders every `code:` binding using **US symbol
names**, regardless of the layout the user selected during installation. On a
Spanish keyboard the menu advertises shortcuts that cannot be typed.

The resize bindings in `default/hypr/bindings/tiling.lua` are bound by keycode:

```lua
o.bind("SUPER + code:20", "Expand window left", ...)
o.bind("SUPER + code:21", "Shrink window left", ...)
```

`omarchy menu keybindings --print` displays them as:

```
SUPER + MINUS                       → Expand window left
SUPER + EQUAL                       → Shrink window left
SUPER ALT + MINUS                   → Expand window left a little
SUPER ALT + EQUAL                   → Shrink window left a little
```

But `code:20`/`code:21` are `<AE11>`/`<AE12>`, and on the `es` layout those
positions are **not** `-`/`=`:

| keycode | XKB name | `us` | `es` |
|---------|----------|------|------|
| `code:20` | `<AE11>` | `minus` | `apostrophe` (`'`) |
| `code:21` | `<AE12>` | `equal` | `exclamdown` (`¡`) |

So the working shortcut is `SUPER + '`, while the menu says `SUPER + MINUS`.
Pressing the key labelled `-` does nothing. This affects every `code:` binding
in the fallback table (`10`–`21`, `59`, `60`, `61`), so digits happen to look
correct while the punctuation keys are wrong on most non-US layouts.

This is a discoverability bug rather than a functional one: the binds fire
correctly on the right physical key. The menu is the only place that tells a
user which key that is, and it names the wrong one.

### Steps to reproduce

1. Install Omarchy selecting a non-US keyboard layout (e.g. Spanish).
2. Run `omarchy menu keybindings --print` (or press `SUPER K`).
3. Observe `SUPER + MINUS → Expand window left`.
4. Press `SUPER` + `-`. Nothing happens.
5. Press `SUPER` + `'` (the key at `<AE11>`). The window resizes.

### Expected

The menu should name the key as it exists on the active layout, e.g.
`SUPER + APOSTROPHE` on `es`.

### Root cause

`bin/omarchy-menu-keybindings`, `parse_keycodes()` (line ~25) resolves keycodes
with:

```awk
keymap_cmd = "xkbcli compile-keymap </dev/null"
```

Invoked with no arguments, `xkbcli compile-keymap` compiles the **default**
keymap (US) rather than the compositor's active one:

```console
$ xkbcli compile-keymap </dev/null | grep -m1 -A1 'key <AE11>'
	key <AE11>               {	[           minus,      underscore ] };
	key <AE12>               {	[           equal,            plus ] };
```

The resolver therefore always agrees with the hardcoded US fallback on line 18
(`20=MINUS 21=EQUAL ...`), and the fallback never visibly "fails" — it is simply
always wrong for non-US users.

Passing the real layout produces the correct symbols:

```console
$ xkbcli compile-keymap --layout es </dev/null | grep -m1 -A1 'key <AE11>'
	key <AE11>               {	[      apostrophe,        question,       backslash,    questiondown ] };
	key <AE12>               {	[      exclamdown,    questiondown,    dead_cedilla,     dead_ogonek ] };
```

### Suggested fix

The script already knows the active keymap — `keybindings_cache_key()` (line
~462) reads it to invalidate the cache:

```bash
hyprctl devices 2>/dev/null | grep -F 'active keymap:'
```

The cache key is layout-aware but the resolver is not, so the layout is
available and simply never threaded into `parse_keycodes()`. Passing it to
`xkbcli compile-keymap --layout "$layout"` (falling back to the current
no-argument call when it cannot be determined) should be enough. The layout code
can be read from `hyprctl getoption input:kb_layout` or from the `layout` field
of `hyprctl devices -j`.

### Related

- #8603 — the inverse case: binds declared by *symbol* (`SUPER + SHIFT + SLASH`)
  that cannot be typed on some layouts, where the suggested fix is to switch to
  keycodes. Worth noting the two interact: moving more binds to `code:` form
  fixes triggering but widens this display bug, so it would be good to land the
  keycode→symbol resolution before converting further bindings.