fix(tui): add force-switch mode hotkey bypassing the mid-session lock

[wqymi]

Problem

In the TUI's agent/mode picker (Select agent), the mid-session lock restricts switching to FREE_SWITCH_GROUP = ["build", "plan"] once a session has messages. There was no way to deliberately switch into any other primary mode mid-session, even when the user knows what they're doing.

Root cause

• The agent picker DialogAgent (component/dialog-agent.tsx) selects via local.agent.userSwitch(name).
• userSwitch is gated by canSwitchTo() in context/local.tsx: once sessionHasMessages is true, switching is restricted to FREE_SWITCH_GROUP = ["build", "plan"]. Any other primary mode hits the lock and shows a "cannot switch mode mid-session" toast.
• The switch mechanism itself is sound: setting agentStore.current triggers the mode-entry effect in app.tsx (dir-switch + sync.bootstrap() for Orchestrator). Only the lock was blocking a deliberate switch.

Fix

• context/local.tsx: add agent.forceSwitch(name) that bypasses canSwitchTo and calls set() directly (which still validates the name against the available agents). The mode-entry effect keys off agentStore.current, so the switch fires exactly like a fresh entry.
• component/dialog-agent.tsx: add a force? prop — in force mode the picker uses forceSwitch and shows a distinct, generic title + hint ("Force switch mode" / "Bypasses the mid-session lock — switch to any available mode"). The normal picker still uses userSwitch (lock respected).
• app.tsx: register an agent.force command (slash /force-agent) bound to the new keybind, opening <DialogAgent force />.
• config/keybinds.ts: add agent_force = <leader>o (previously unused), described generically as "Force switch mode (bypass mid-session lock)".
• i18n titles (en / zh / zht) use generic "Force switch mode (bypass mid-session lock)" phrasing — no mode is singled out.

This is a generic force-switch: it bypasses the mid-session lock to switch to any available mode. It does not special-case or name any particular mode.

Orchestrator visibility is flag-gated (unchanged)

Orchestrator is one of several modes and is registered behind Flag.MIMOCODE_EXPERIMENTAL_ORCHESTRATOR in agent/agent.ts. When the flag is OFF, orchestrator is not added to the agent set → absent from Agent.list() → absent from sync.data.agent → therefore absent from the picker, the Tab-cycle, and the new force-switch (which validates against the available agents). When the flag is ON, it appears and is selectable. Force-switch does not expose it when the flag is off.

Verify

• bun typecheck → 12/12 successful (EXIT 0).
• bun test test/agent/orchestrator.test.ts test/agent/agent.test.ts test/keybind.test.ts → all pass.
• Added a subprocess-based regression test (test/agent/orchestrator.test.ts + test/agent/fixtures/list-agents-probe.ts): Orchestrator is absent from Agent.list() when MIMOCODE_EXPERIMENTAL_ORCHESTRATOR is OFF and present when ON. (A subprocess is required because test/preload.ts force-enables the flag for the suite and Flag is read once at import.)
• Live TUI: in a session with messages, <leader>o (or /force-agent) opens the force picker and switches to the selected available mode; normal Tab-cycle and <leader>a picker remain locked to build/plan mid-session as before.