Delete the TUI key-translation round-trip through crossterm (~300 lines) — share one decoder with GTK

[JDonaghy]

Problem

The TUI takes a quadraui::Key from the runner, converts it back into a crossterm event, then re-decodes it:

1. src/tui_main/shell_app.rs:3614 — synth_keyevent turns the quadraui::Key back into crossterm
2. src/tui_main/mod.rs:809-911 — translate_key (103 lines)
3. src/tui_main/mod.rs:789-808 — tui_key_to_engine_name
4. src/tui_main/mod.rs:753-788 — shift_map_us
5. src/tui_main/shell_app.rs:3171-3578 — ~200 lines of per-panel KeyCode tables inside handle_focus_owner_key

GTK decodes the same quadraui::Key to the same engine names in ~40 lines inline (src/app.rs:6807-6850) plus map_gtk_key_name (:617-639).

Both produce identical spellings — "Escape", "Return", "BackSpace", etc. The TUI's round-trip through crossterm is pure overhead, and it is the largest single block of TUI-only code that is not irreducible: ~300 lines.

Fix

One shared decoder in render.rs:

render::engine_key_from_ui(key, mods, keyboard_enhanced) -> (String, Option<char>, bool)

Delete synth_keyevent, translate_key, tui_key_to_engine_name and shift_map_us; have both backends call the shared function. The per-panel KeyCode tables in handle_focus_owner_key should then be expressible against engine key names rather than crossterm variants.

Watch keyboard_enhanced — the TUI sets it in setup and it changes how some chords arrive. It must be a parameter of the shared decoder, not a TUI-local branch.

Note for reference: <C-h>, <C-j> and <C-c> arrive as ctrl+h/ctrl+j/ctrl+c under crossterm; the Vim-conformance chain (#800-807) depends on those spellings. Do not change the engine-facing names.

Acceptance

• Black-box tests required, both backends. Key decoding is the highest-blast-radius surface in the editor.
• Cover: plain keys, shifted keys, ctrl chords, alt chords, function keys, Escape/Return/BackSpace/Tab, and per-panel focus routing.
• The Neovim-oracle harness (tests/nvim_conformance.rs, 1,432 cases behind KNOWN_DEVIATIONS) is the regression net here — it must stay green, and no label may start passing or failing unexpectedly.
• State in the PR that the new tests fail against unfixed develop.

[JDonaghy]

Before you start: re-verify the citations, do not trust them

Every file:line in this issue was measured on develop @ ee26268 (2026-09-04) by an audit, not by reading the tree you will check out.

They will have drifted by the time you pick this up. This issue sits in a serialised chain, and several entries ahead of it move code on purpose — #812 deletes ~1,300 lines from src/render.rs, #813 retypes fields in src/app.rs, #785 and #814 delete whole functions. Anything filed after those shifts.

So:

• Locate by symbol, not by line. grep -n "fn build_screen_layout_with_breadcrumb_row" src/render.rs, not "go to line 12886". GOALS.md already carries this rule for the same reason — it cites no line numbers on purpose.
• Re-measure any count before you use it. Line totals here came from python3 scripts/prod_lines.py and scripts/native_lines.py at a named revision. Re-run them rather than quoting the number in this issue. GOALS.md: "regenerate them with the script rather than trusting the table."
• Size the branch from what you find, not from the figure here. The counts are evidence that a problem is large, not estimates of a diff.

If a finding does not reproduce, say so — that is a useful result

This issue was generated from an automated audit. Some of its claims are wrong. Today alone, two confident findings in the same audit chain did not survive checking: a "1,671 byte-identical lines" figure measured out at ~85, and a "zero commits of pin lag" reading was taken against a stale local ref and was actually 42.

If the problem described here is already fixed, was never real, or is real but different from the description: comment with what you actually found and stop. Do not implement around a bad premise to make the issue closeable. A correction is worth more than a merged PR built on a wrong claim.