feat(nano): nano badge in the web client

[agentforce314]

Client half of the web-UI ↔ nano integration (backend: #901). The browser client now shows the backend's nano mode (clawcodex web --nano, docs/nano.md) on three surfaces, all driven by the gateway wire fields #901 added:

• the composer row — a green nano fact chip after the effort picker, the TUI status line's model effort nano order. A span, not a control: nano is a launch flag, there is nothing to toggle.
• the run-stats line — the chip rides the model segment (RunStatsBar), so whatever narrows the bar can never shed the mode without also shedding the model it describes (the TUI stats-line contract).
• the session details panel — a Harness: nano fact row, rendered only when the session IS nano.

Sourcing mirrors the composer's model/approval fallbacks: the session's own session.info.nano once one exists, else $backendNano — a new boot fact read from /api/status, which is what lets the welcome screen say what the first prompt will run on before it is sent. Strict === true everywhere, so older backends without the field never grow a badge.

Tests: 8 vitest in NanoBadge.test.tsx (composer chip render/absence/not-a-button, stats-bar ride-along + absence + no-model case, details row presence/absence) + a transcript merge pin (nano survives a session.info republish that omits it — matching the backend, where _install_provider keeps the nano registry). npm run check: 418 tests green, typecheck clean; vite build clean.

Verified live against clawcodex web --nano (deepseek): hero chip from /api/status before any session; a real fix-the-bug turn on the six-tool surface (Read → Edit → Bash verify, fix landed on disk); mid-session model switch keeps chip, details row, and registry (second turn green); WS wire probes (session.create with explicit provider/model, config.get, session.active_list) all nano: true; default-mode control run shows no chip anywhere and nano: false on every wire field; dark-theme chip legible.

🤖 Generated with Claude Code