lib/ui: dispatch ignores key events — keyboard routing (hotkeys, focus nav, text input) lives only inside app_loop

[InauguralPhysicist]

Found by DeslanStudio milestone 4b. The consumer contract for headless testing (tests/test_ui.eigs: stub gfx_*, build the tree, drive ui.dispatch with synthetic events) covers mouse and wheel — but dispatch of [root, {"type": "keydown", ...}] silently returns null. All keyboard routing (the _match_hotkey priority, escape-pops-modal, combobox keys, _handle_text_key, _handle_focus_key) is INLINE in app_loop's keydown branch, which a headless test can never reach (it blocks on gfx_poll).

Consequences for a real app shell:

• menu shortcuts (register_hotkey of ["ctrl+s", ...]) are untestable through the public event path; tests must call the private _match_hotkey directly and trust that app_loop's priority order matches,
• the same for text_input typing and Tab-focus navigation — test_ui.eigs itself already resorts to calling _handle_focus_key directly.

Suggestion: extract app_loop's keydown block into a public handle_key(root, ev) (returning 1 if consumed) that app_loop calls, and/or route keydown/keyup through dispatch. Then a headless consumer drives keyboard exactly like mouse, and the priority order is pinned by tests instead of duplicated.

Downstream workaround (DeslanStudio tests/test_shell.eigs): assert hotkey behavior via _match_hotkey directly, with a comment pointing here.