### What happened

Pressing `SUPER + K` (keybindings menu, `omarchy-menu-keybindings`) does nothing: the menu never appears. The process silently spins at ~100% CPU forever.

### Root cause

`omarchy-menu-keybindings` scans the user's config by `dofile`-ing `~/.config/hypr/hyprland.lua` under a stub environment in which every `hl.*` call returns a shared "noop" proxy table (with `__index` returning another noop).

Any user config that iterates monitors with `ipairs(hl.get_monitors())` at load time hangs forever in that environment, because `ipairs` resolves every index through `__index`, which always returns the noop table — the loop never reaches `nil`.

### Steps to reproduce

1. In `~/.config/hypr/monitors.lua` add at load time:

```lua
local function workspace_monitors()
  local external, laptop
  for _, monitor in ipairs(hl.get_monitors()) do
    if monitor.name == "DP-1" then external = monitor end
    if monitor.name == "eDP-1" then laptop = monitor end
  end
  return external, laptop
end
workspace_monitors()
```

2. Press `SUPER + K` — the menu never opens; `omarchy-menu-keybindings` spins at 100% CPU.
3. Confirm with `omarchy-menu-keybindings --print` — it produces no output and never exits.

### Expected

The mock `hl` environment used by the bindings scanner should behave like an empty monitor list so `ipairs` terminates (e.g. have `get_monitors()` return a real empty table, or give the noop proxy a `__len`/`__index` that returns `nil` for numeric keys). User configs shouldn't hard-hang the menu scanner.

### Workaround (user-side)

Iterate with a numeric for instead of ipairs:

```lua
local monitors = hl.get_monitors() or {}
for i = 1, #monitors do
  local monitor = monitors[i]
  ...
end
```

(`#noop` is 0 since the proxy has no array part, so the loop terminates.)

### System details

- Omarchy: 4.0.3-1
- CPU: Intel Core Ultra X7 358H
- GPU: Intel Arc B390 (Panther Lake)
- Kernel: 7.2.3-arch1-1-ptl