feat(settings): add foreground fallback controls

[RaresKeY]

Summary

This replaces #5684, which GitHub closed during the repository transfer and fork-network separation. The branch has been rebuilt on the current dev history; the implementation scope is unchanged.

Settings now exposes an off-by-default per-user foreground fallback toggle and an ordered editor for concrete endpoint/model candidates. The editor writes only the replacement policy keys, never displays or migrates legacy fallback data, and uses the same owner, allowlist, endpoint-type, model-inventory, and runtime-credential boundaries as backend routing.

Target branch

• This PR targets dev, not main. All PRs land in dev; main is curated by the maintainer at each release. If your PR is on main by accident, click "Edit" on this PR and change the base.

Linked Issue

Fixes #5627

Part of #5625

Depends on #5683

Type of Change

• Bug fix (non-breaking — fixes a confirmed issue)
• New feature (non-breaking — adds new behaviour)
• Breaking change (changes or removes existing behaviour)
• Refactor / cleanup (behaviour unchanged)
• Documentation only
• CI / tooling / configuration

Checklist

• I searched open issues and open PRs — this is not a duplicate.
• This PR targets dev
• My changes are limited to the scope described above — no unrelated refactors or whitespace changes mixed in.
• I actually ran the app (docker compose up or uvicorn app:app) and verified the change works end-to-end. Type-checks and unit tests are not enough.

Stack

This is the third PR in #5625: #5632 → #5683 → this PR.

Until the preceding PRs merge, GitHub shows the three-commit stack. The issue-specific commit is 266281699442d398cd1fd51c239e427ade9ec417.

Behavior contract

• The toggle is per user and off by default.
• Disabled policy or an empty candidate list remains strict.
• Candidates are unique concrete endpoint/model pairs in explicit order.
• Users can add, remove, and reorder up to ten candidates.
• default_model_fallbacks is never displayed, copied, or migrated.
• Owner scope, model allowlists, block-all policy, LLM endpoint type, hidden models, and runtime credentials match backend eligibility.
• Unknown catalogs remain distinct from known-empty catalogs.
• Existing unavailable rows remain visible as unavailable rather than being replaced.
• Loading, refresh, and preference-write failures disable changes and expose Retry.
• A failed candidate-list save cannot be masked by a later successful enable action.
• Copy explains that only availability failures are eligible; request, authentication, authorization, unsupported-model, and configuration failures surface directly.

Scope

In scope: the Settings toggle, ordered editor, foreground-safe model catalog, persistence, failure recovery, keyboard focus, responsive layout, and service-worker caching.

Out of scope: per-message overrides, inferred model profiles, provider discovery, capability inference, legacy-data migration, and controls for Utility, Vision, Deep Research, tasks, teacher, image, embedding, or search providers.

Validation

• Canonical GitHub Actions Python tests: passed.
• Python compilation: passed.
• JavaScript syntax checks: passed.
• CodeQL, dependency review, secret scanning, workflow security, and container checks: passed.
• Focused Settings, API, and routing regression suite: 520 passed.

Desktop/mobile browser validation and screenshots remain outstanding, so this PR remains draft.

How to Test

1. Open Settings → AI as a new user and confirm fallback is off and the editor is hidden.
2. Enable fallback, add concrete candidates, reorder and remove them, then reload.
3. Disable and re-enable the policy; confirm the saved list is retained but inactive while off.
4. Confirm legacy fallback values never populate the editor.
5. Confirm separate users see only their own eligible endpoints and policy.
6. Exercise restricted, hidden, non-LLM, and unavailable provider-auth candidates.
7. Fail a list save and confirm enabling remains blocked until Retry reloads persisted state.
8. Verify keyboard operation and layout at desktop and mobile widths.

Visual / UI changes — REQUIRED if you touched anything that renders

• Screenshot or short clip of the change in the running app, attached below. Mobile screenshot too if the change affects mobile.
• Style match: the change uses Odysseus's existing visual language. Specifically:
  • Reuse existing CSS variables (--red, --fg, --bg, --card, --border, etc.) — do not introduce new color values, font sizes, or spacing units.
  • Reuse existing button/input/card/border classes. Don't invent parallel styling.
  • No Unicode emoji in UI or code. Use inline SVG (matching the monochrome icon style already in static/index.html) or plain text.
  • Monospaced font (Fira Code) for primary UI text. Don't override.
  • Dark theme is the default; any light-mode work must be wired through the existing theme system, not hard-coded.
• No new component patterns. If a similar widget already exists in the app, extend it instead of writing a parallel one.
• I am not an LLM agent submitting a bulk PR. If you are, please open an issue describing the problem first — bulk auto-generated PRs that don't match the project's visual style are closed on sight, even when the underlying fix is correct.

Screenshots / clips

Not included. Desktop/mobile browser validation and screenshots remain outstanding.