feat(companion): make all enabled backends selectable (Codex + Claude)

[claudiusthebot]

Problem

Dylan has both Codex and Claude backends enabled on the gateway, but the companion app only ever showed Claude. Root cause: the native bridge never exposed the backend layer at all — it had listModels/setModel but no concept of backends. (Telegram already has a /model backend submenu; the bridge was the gap.)

Fix — fully gateway-driven, nothing hardcoded

Bridge / engine

• protocol: ClientChat gains backend; new BackendOption type.
• server: GET /backends?chatId= and POST /backend. /backend always returns 200 with {ok,error} (the client decoder drops ≥400 bodies, and this is an app-level result).
• index: listBackends() returns the enabled backends (listAvailableBackends(config), honouring enabledBackends) + the chat's active one; setBackend() mirrors the Telegram flow — verify enabled → rebindChat → pin override → reset session/history/pulse (sessions aren't portable across backends) → broadcast chat_updated + status. listModels() takes an optional chatId so the active-model hint tracks the chat's backend.

Client

• BackendOption model; ClientChat.backend; BridgeClient.backends()/setBackend(); AppState.backends()/setBackend()/refreshModels(chatId).
• Model sheet: a BACKEND chip row (only shown when >1 backend is enabled), a switching spinner, a "starts a fresh conversation" note, and a SnackBar on failure.

Whatever the gateway reports as enabled is what shows — no assumptions about specific backends/models.

Test

tsc --noEmit clean · flutter analyze lib → No issues · native-frontend + bridge suites (25) pass.

Stacked on #417 → #415 (native-frontend chain, avoids index.ts conflicts). Merge order: #415 → #417 → this. Diff here is only the backend-selector work.

🤖 Generated with Claude Code