Keyboard navigation: must work completely and be discoverable

[tig]

Problem

Every clet must be fully operable by keyboard alone — no mouse required, no hidden key combinations, no focus traps. Shell scripts can't use a mouse. AI agents certainly can't. This is a hard correctness requirement, not a nice-to-have.

Beyond correctness, the keybindings must be obvious: discoverable from the UI itself, consistent across clets, and documented in clet help <alias> output. Right now, some clets show their keys; some don't. A user who doesn't already know TG's conventions is guessing.

clet is also a natural integration harness for Terminal.Gui's keyboard handling. Issues found here should be filed upstream in gui-cs/Terminal.Gui — this repo can serve as a reproducible test bed.

Definition of done

Spec: add §6.9 keyboard-nav checklist

A manual (or TUIcast-driven) checklist covering:

• Tab / Shift-Tab moves focus between all interactive controls
• Enter confirms; Esc cancels — for every input clet
• Arrow keys navigate lists (select, multi-select, attribute-picker, pick-file, pick-directory)
• Space toggles selection in confirm and multi-select
• No focus traps: Esc always exits
• Visible focus indicator present in all four terminal themes (§6.5 matrix)
• clet range low/high fields navigable by Tab, adjusted by arrow keys

Implementation: keybinding visibility

• Each input clet's --help output documents its non-obvious keybindings
• Status bar or footer shows primary keys (Enter/Esc minimum) during interaction

Upstream

• Any TG keyboard bug found during this work gets filed in gui-cs/Terminal.Gui with a clet repro

Cost

Checklist: half a day to write. Execution: per-release manual (or automated via TUIcast once #BR-7 unblocks the harness). Keybinding docs: per-clet, small.

Originally tracked as #BR-9 in bar-raise backlog issue #11. Refactored from "accessibility test layer missing" — the real requirement is keyboard-completeness and discoverability, not screen-reader support specifically.