feat(tui): Run submenu — Local · Cloud · Fusion with a fusion share dial

[plombeer31]

Stack: 3 of 3. Based on feat/fusion-routing (#162), which is based on feat/run-mode-config (#161). This PR's diff is the operator surface and the docs.

This is where the feature becomes usable.

What it looks like

A one-row pill strip under the status bar in chat mode:

▸ Local  ·  Cloud  ·  Fusion 40%

Ctrl+R cycles it. /run opens a dial overlay; /run fusion 60 switches directly.

A persistent strip rather than a one-shot overlay because a run mode is a state you are in — an operator has to see at a glance whether the next turn spends cloud tokens. ThemePicker/SessionPicker are the wrong precedent for that part. The overlay exists only because a 0-100 dial cannot fit in a one-row strip.

Two structures that look like the obvious homes, and why they are not

DebugPane's SubTabBar has an if (section === "run") return null branch that reads exactly like an extension point. It is unreachable: DebugPane only renders when uiMode !== "chat", so a submenu hung off it would never display. The strip is a new row rendered by TuiApp; debug-pane.tsx is untouched.

cycleSubTab returns TuiTabs. Run modes are not tabs, and forcing them into that union would drag in getCurrentSection, tab_changed, NAV_SLOT_ORDER and the persisted initialLayout contract for something none of them describe. section.ts is untouched and its tests stay green.

Keyboard

Ctrl+R cycles from any section — run mode is global, not chat-local. Verified free: app-key-bindings.ts binds only Ctrl+C and Ctrl+B, and MultiLineEditor bails on every ctrl chord outside a/e/u/k/w/c/o.

The overlay claims keys inside handleAppKey, beside the approval and update prompts, rather than through submit-handler as the other Run-section overlays do. That divergence is deliberate: the dial needs ←/→ and digits, which the focused chat editor would otherwise consume as cursor motion and literal text. While open it returns true for every key — the same total-swallow discipline as the Fallback pane's add-picker — so nothing leaks into the editor, the nav cycle or the slash palette behind it.

One pinned test knowingly rewritten

slash-commands.ts registered { name: "chat", aliases: ["run"] }, pinned by slash-command-handler.test.ts. /run becomes its own command, so that test is replaced — but the behaviour it protected is preserved and re-pinned: bare /run still returns to the Run section, and now additionally opens the picker. Muscle memory survives; the name now also owns the thing it is named after. (/local is left alone — it is already an alias of /model.)

Persistence

RunModeOrchestrator is the only TUI writer of llm.runMode. It persists both config keys in one write before touching the runtime, so a failed provider swap still leaves a file that boots into the requested mode — and the error says so rather than pretending the switch did not happen. It also refuses to write a mode that would immediately resolve to something else, surfacing the degradation sentence instead of leaving the strip disagreeing with the file.

Docs

• AGENTS.md: a new ## Run modes (Local / Cloud / Fusion) section after ## Provider fallback chain — config rule, degradation, the step table, the score (including why cacheReused is excluded), slot/KV behaviour, provider lifetime, what fusion does not cover, the TUI surface, and 11 pinned invariants. Plus three module-map rows and invariant 11 on the fallback chain.
• README.md: a run-modes block under Ways to Use It, /run in the slash-command line, and the llm.runMode shape under Requirements & Configuration.

Verification

npm run lint and npm run build clean. npm test: 4202 passed. The 6 failing files are the same ones that already fail on main @ 667dae1; llm-health-poller is the documented load-flake (passes 2 runs in 3, and this branch does not touch it).

54 new tests: reducer, nav, picker keys, both components (ink-testing-library), persistence, and the /run parser.

End-to-end against the built dist/, with a two-provider config and a simulated 5-step turn:

1. fresh install      -> local
2. after /run fusion  -> fusion | share 60 | cloud openrouter | local local-llama
3. simulated turn:
     step 0 (6000 tok)  -> orchestrator openrouter  complexity 8
     step 1 (7000 tok)  -> executor     local-llama complexity 11
     step 2 (9000 tok)  -> executor     local-llama complexity 16
     step 3 (15000 tok) -> executor     local-llama complexity 30
     step 4 (26000 tok) -> orchestrator openrouter  complexity 52
4. sub-runners        -> local-llama
5. hand-swap to local -> local (stored still fusion)
6. router now         -> null
7. cloud w/o provider -> local | Cloud mode needs a cloud provider — none is configured. …

Step 0 plans on the cloud, the mechanical middle stays local, and the 26k-token synthesis step escalates back to the cloud on context pressure alone — with no special-casing, which is the design claim in #162 working in practice. Line 5 is the non-contradiction rule: changing the provider by hand drops the mode out of fusion with no reconciliation step.