fix: make provider fallback policy explicit and visible

[OmarB97]

What changed

• Adds an explicit fallback_policy with off, local-only, and any modes.
• Enforces that policy before startup/auth fallback and during live turns across CLI, one-shot, gateway, cron, delegated/background agents, and the core runtime.
• Refreshes config-owned fallback chains between turns so deletion, reordering, and policy changes take effect without recreating the agent.
• Emits a structured fallback decision before switching routes, while keeping rejection/exhaustion terminal and preventing duplicate switch notices.
• Persists bounded fallback notices in the Desktop transcript sidecar so reload/resume keeps the operator-visible routing explanation without injecting it into model context.
• Documents the policy and exposes hermes fallback policy management.

Why

Fallback routing was assembled and cached independently by several entry points. That let init-time auth recovery bypass the live policy, made stale routes survive config changes, and could switch a turn to another provider without a durable user-facing explanation. The result was especially confusing when a local Hermes deployment silently recovered through a remote/free provider.

This change makes routing eligibility a shared policy boundary and treats the fallback decision as observable runtime state rather than incidental console text.

Safety and compatibility

• off fails loudly without attempting a backup route.
• local-only admits only routes whose endpoint/provider metadata proves they are local; unknown endpoints fail closed.
• any preserves the historical configured-chain behavior for existing configs.
• Manual /model selections remain excluded from automatic fallback for the active session.
• The branch is rebased on fork main at TTS-state containment e1754474b6 (test(gateway): stop TTS state leaking into later tests #268), with browser-test containment 28f371dc8b ([Hermes][Browser tests][1/n] Prevent real Chrome launch in retry test #266) immediately below it. Their patch IDs exactly match source commits 8f58ce2b553dbf1a7b0f500849fa540e11f492b0 and 398ed14ef, respectively.

Validation

• scripts/run_tests.sh on 18 affected non-TUI Python files: 1,141 passed.
• Narrow cron selection for init-auth fallback propagation and cron session titles: 2 passed.
• Desktop workspace Vitest on seven affected files: 88 passed.
• Desktop TypeScript typecheck: passed.
• ESLint on every changed Desktop TypeScript/TSX file: passed.
• git diff --check: passed.
• Independent exact-diff review: no P0/P1 findings.

tests/test_tui_gateway_server.py was intentionally not executed because its browser/TTS test isolation was under active containment review. No live application was launched, installed, restarted, or modified.

The repository-wide Desktop lint command still reports one pre-existing sort-import error and one hook-dependency warning in unchanged files (use-prompt-actions/submit.ts and settings/model-settings.tsx); neither file is in this diff.

Known review follow-ups (non-blocking P2)

• Same provider/model/base-URL eligibility identity does not yet include api_key/key_env/api_mode, so an active fallback client can retain same-route credential changes until the primary cooldown ends.
• API-server agents do not currently pass a status_callback, so fallback status is server-visible but not yet streamed to that API client surface.
• Partial-stream content-filter handling can use misleading terminal wording and retry a deterministic filter when policy leaves no eligible route.
• Desktop notice persistence is keyed by stored session ID rather than profile + session ID, and the pre-bind pending map is not explicitly bounded.

This is intentionally a draft for focused review of those boundaries and the cross-runtime behavior.