### What happened

`omarchy-menu-keybindings` (SUPER + K) never opens. The process hangs indefinitely — no menu, no error, no timeout. `omarchy-menu-keybindings --print` also hangs.

The hang is triggered by any user Lua config that iterates one of Hyprland's list getters (`hl.get_monitors()`, `hl.get_windows()`, `hl.get_workspaces()`) with `ipairs` at config-evaluation time.

### What I expected

The keybindings menu opens and lists the bindings, or fails loudly.

### Steps to reproduce

On Omarchy 4.0.0 (quattro), add a single line to `~/.config/hypr/monitors.lua`:

```lua
for _, monitor in ipairs(hl.get_monitors()) do end
```

Then run:

```bash
omarchy-menu-keybindings --print   # hangs forever
```

Hyprland itself is fine — `hyprctl reload` and `hyprctl configerrors` are clean, and the config behaves correctly at runtime. Only the keybindings scanner hangs.

### Root cause

`build_lua_bind_cache()` in `omarchy-menu-keybindings` re-evaluates `~/.config/hypr/hyprland.lua` in a bare `lua` interpreter, with `hl` replaced by a catch-all stub (bin/omarchy-menu-keybindings, around lines 181-232):

```lua
local noop
noop = setmetatable({}, {
  __index = function() return noop end,
  __call  = function() return noop end,
})
```

Because `__index` answers **every** key with a truthy value, `hl.get_monitors()` returns `noop`, and `ipairs(noop)` reads index 1, 2, 3, … without ever hitting `nil`. Infinite loop inside the `lua` subprocess. The `while read` loop feeding off it in bash blocks forever, so the menu never renders.

The stub already special-cases one getter to return a real value:

```lua
get_config = function()
  return nil
end,
```

The list getters just were not covered.

### Suggested fix

Stub the list getters with real empty tables, so iteration terminates:

```lua
get_monitors   = function() return {} end,
get_windows    = function() return {} end,
get_workspaces = function() return {} end,
```

A timeout around the `lua` subprocess would also turn this class of failure into a degraded menu instead of a silent hang.

### Why this probably was not caught

No config under `/usr/share/omarchy/default/hypr/` calls any `hl.get_*` getter at load time (`grep -rn "get_monitors\|get_windows\|get_workspaces" /usr/share/omarchy/default/hypr/` returns nothing), so the stock configs never hit it.

Third-party Lua modules do. Unmodified upstream [shezdy/hyprsplit](https://github.com/shezdy/hyprsplit) `init.lua` iterates all three getters, so any user requiring it from their Hypr config gets the same hang.

My own trigger was dynamic monitor placement — computing the laptop's position from the live external monitor geometry, rather than hardcoding `auto-right`.

### Workaround

Guard in `~/.config/hypr/hyprland.lua`, right after the bootstrap `dofile`, detecting the stub (raw slot empty but `__index` conjures a value) and handing back real empty lists:

```lua
local probe = hl.get_monitors()
if type(probe) == "table" and rawget(probe, 1) == nil and probe[1] ~= nil then
  hl.get_monitors = function() return {} end
  hl.get_windows = function() return {} end
  hl.get_workspaces = function() return {} end
end
```

With that in place `omarchy-menu-keybindings --print` exits 0 and lists all 231 bindings.

### System details

- Omarchy 4.0.0-1 (stable channel)
- Hyprland 0.56.2-1
- Lua 5.5.1-1
- CPU: AMD Ryzen AI 7 PRO 350 w/ Radeon 860M
- GPU: AMD Radeon 840M / 860M Graphics (Krackan)