feat(tui): add C-x o / C-2..C-5 / Shift+Arrow split-pane focus keys

[edwin-zvs]

What

Adds Emacs-style fast focus-movement keys for the TUI split-session layout, so you can hop between panes without cycling.

Key	Behavior
C-x o	Cycle focus list → split windows → list (Emacs other-window) — already existed, unchanged.
C-2 … C-5	Focus a pane directly. Pane 1 is the session list, pane 2 is the first split window, etc. — so C-2 focuses the first split window, C-3 the second, … No-op when that pane doesn't exist.
Shift+↑/↓/←/→	Move focus to the spatially adjacent split window in that direction (Emacs windmove). Scoped to a focused, unzoomed multi-pane split; a press with no neighbor that way is a consumed no-op.

How

• New helpers in app.rs: focus_pane_by_index (shared [list, …windows] ordering, same order C-x o walks) and adjacent_window_id / focus_adjacent_window (closest pane whose perpendicular span overlaps the active one). Spatial adjacency reuses the per-frame main_window_areas geometry already tracked for mouse hit-testing.
• Intercepted in on_key ahead of PTY forwarding and chord dispatch, so these keys escape a focused child's PTY exactly the way the C-x prefix does. Without that they'd be useless in their main scenario — leaving a pane that's running an interactive child. This mirrors the existing PageUp/PageDown scrollback intercept.
• Contextual Shift+Arrow: only takes over the arrows when the view pane is focused in an actual multi-pane split (not zoomed). On the list, Shift+↑/↓ keep doing list-reorder; single-pane views pass the key through to the child. No keymap bindings were repurposed.

Why an on_key intercept instead of new keymap entries

SwitchFocus/C-x o reaches the TUI from inside a live PTY because C-x is the escape prefix. C-2..C-5 and Shift+Arrow are not C-x chords, so a keymap binding alone would be swallowed by the focused child. Handling them in on_key (the same place PageUp/PageDown and the C-x C-x literal-escape live) is the established pattern for "global keys that shadow the child".

Tradeoffs

A full-screen child in a focused split no longer receives those exact keys while a neighbor exists — the same accepted tradeoff already made for scrollback paging. Documented in spec 0061-split-pane-focus-keys-are-global.md (complements 0055, whose non-goal previously said the global-chord set wasn't changing).

Tests

cargo build + cargo clippy clean. New unit tests:

• c_digit_focuses_pane_by_index — C-2/3/4 focus windows 1/2/3; C-5 no-op with 3 windows.
• focus_pane_index_zero_is_the_list — pane 1 is the list.
• shift_arrow_focuses_spatially_adjacent_window — 2×2 grid: right/down/left/up neighbor resolution + no-neighbor no-op.

Existing switch_focus_cycles_*, keymap::*, and help-modal tests still pass.

Where the code lives

Only crates/cli → the relevant binary is construct (target/debug/construct).