Fix infinite iteration in Lua keybindings scanner

[filippov-au]

Opening the keybindings menu can hang at 100% of one CPU core when custom Hyprland configuration iterates over a runtime collection, such as ipairs(hl.get_monitors()). For example, monitor configuration may check whether a streaming output exists before disabling another output. That loop completes normally in Hyprland but never finishes in the menu’s Lua scanner.

The scanner substitutes a callable noop table for unsupported Hyprland APIs. Its __index returns that same table for every key, so ipairs never reaches nil. Return nil for numeric lookups so these placeholders behave as empty collections, while retaining named lookups and calls. This lets the scanner continue collecting bindings without requiring menu-specific guards in user configuration.

Extend the existing keybindings menu test with monitor and nested window-tag loops, a normal configuration call, and a binding declared after the loops. A timeout catches the original hang; checking the resolved binding also catches a scan that exits early with an error.

Validation:

• The regression test fails against the unmodified scanner and passes with the fix.
• bash test/shell.d/keybindings-menu-test.sh, Bash syntax checks, and git diff --check pass.
• Ran ./test/all against both upstream and the patch: the CLI suite passes, and both have the same three environment-related shell test failures. All three pass on both versions when rerun with the required setup: unset NO_COLOR for launch-about, allow route lookup for network-qr, and provide the omarchy-iso checkout for snapper. No new test failures.

[bjarneo]

Automated duplication check: this pull request looks similar to #8876, which covers the same keybindings scanner ipairs termination fix. I keep that one open and close this one to consolidate review.

If you feel this is the wrong decision, please open the PR again with a note on the difference.