**Omarchy version:** 4.0.4 (Lua Hyprland config)

## What happens

SUPER+K never opens the keybindings menu. `omarchy-menu-keybindings --print` hangs with no output. Each press leaves a `lua` process spinning at 100% CPU (I had 18), and an empty `~/.cache/omarchy/keybindings.XXXXXX` file behind (I had ~70).

## Cause

`build_lua_bind_cache` loads `~/.config/hypr/hyprland.lua` against a stub `hl`. Unknown fields resolve to `noop`, whose `__index` and `__call` both return `noop`:

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

So `hl.get_monitors()` (or any `hl.get_*()`) returns `noop`, and `noop[i]` is never nil. Any user config that runs at load time like

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

loops forever (`ipairs` honours `__index`, Lua 5.5). The bash `while read` loop around the `lua <<'LUA'` heredoc then waits forever too.

## Minimal repro

Add to `~/.config/hypr/hyprland.lua`:

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

Hyprland itself is fine, but `omarchy-menu-keybindings --print` now never returns.

## Suggested fixes

1. Make the stub safe to iterate. For example, have `noop`'s `__index` return `nil` for integer keys, or have stubbed `hl.get_*` return `{}`.
2. Run the Lua scan under a `timeout`, so a bad user config degrades the menu (e.g. no Lua binds listed) rather than hanging it.
3. In `refresh_keybindings_cache`, clean up `tmp_file` with a `trap` on EXIT/INT/TERM. Today it is only removed when `output_binding_records_uncached` returns non-zero, so a hung or killed run leaks it.

## Workaround

In user config, copy `hl.get_*()` results with `rawget(t, i)` before iterating.