feat(settings): expose per-user foreground fallback controls

[RaresKeY]

Prerequisites

• I searched open issues, open PRs, and discussions for foreground fallback settings controls.
• This is the focused UI child of fix/refactor(models): make selected-model routing strict and fallbacks explicit #5625 and depends on the backend policy in refactor(models): centralize explicit foreground fallback policy #5626.
• This proposal uses concrete models and does not add inferred big/small profiles.

Area

UI / Frontend

Problem or Motivation

The replacement foreground fallback policy must be a per-user choice. A stored candidate list alone is not consent to switch providers, and the existing default_model_fallbacks editor writes legacy data that the replacement backend intentionally does not read.

Users need one clear control that says whether a selected Chat/Agent model may fall back, plus an ordered list of concrete endpoint/model candidates that is created under the new policy. The default must remain strict.

Proposed Solution

Update Settings to expose the new per-user foreground fallback policy from #5626:

• add an Allow fallback when the selected model is unavailable toggle, off by default;
• keep the ordered candidate editor disabled or hidden while the toggle is off;
• save candidates to the new policy key, never to default_model_fallbacks;
• do not prepopulate or migrate the new list from legacy fallback values;
• explain that fallback is limited to availability failures and that authentication, request, and configuration errors are surfaced directly;
• reuse the existing endpoint/model selector patterns and visual language;
• preserve owner isolation so one user's choice and candidates do not affect another user;
• remove or relabel the legacy foreground fallback editor so it cannot imply that stored legacy values remain active.

Parent Tracker

Part of #5625.

Depends On

• Agent-mode tool-call rounds can resolve to a different model than the UI-selected one, causing unexpected API calls and rate-limit errors #4561 for strict foreground routing.
• refactor(models): centralize explicit foreground fallback policy #5626 for the new per-user backend policy and candidate schema.

Scope

In scope:

• per-user Settings toggle;
• new ordered concrete endpoint/model list editor;
• load/save behavior for the new policy keys;
• clear strict/off and explicit/on copy;
• owner isolation;
• existing-component reuse;
• frontend source tests, API/settings tests, and browser validation with screenshots.

Out of scope:

• inferred big/small model choices;
• automatic migration from default_model_fallbacks;
• Utility, Vision, Deep Research, task, teacher, image, embedding, or search-provider fallback controls;
• per-message or composer-level overrides;
• new provider discovery or model capability inference.

Acceptance Criteria

• A new user's fallback toggle is off.
• With the toggle off, the UI states that the selected foreground model is strict and no fallback candidate editor is active.
• Turning the toggle on allows an ordered list of concrete endpoint/model candidates to be added, removed, and reordered.
• Save/reload preserves the toggle and list only for the authenticated user.
• Legacy default_model_fallbacks data is neither displayed as active nor copied into the new list.
• Empty explicit lists are handled clearly and do not imply that automatic model selection will occur.
• Existing Settings control and selector patterns are reused without new visual conventions.
• Desktop and mobile browser checks confirm the control is readable and operable.
• Frontend syntax, focused settings/model-route tests, and the stacked integration smoke test pass.

Alternatives Considered

• Reuse the legacy editor and add a toggle beside it. Rejected because the legacy values must remain disconnected from the replacement policy.
• Enable fallback automatically when a list is nonempty. Rejected because provider switching requires explicit per-user consent.
• Add a Chat composer toggle. Deferred because per-message/session state would broaden the first UI slice.
• Offer big/small profiles. Rejected in favor of explicit concrete models and order.

Prior Art / Related Issues

• Parent tracker: fix/refactor(models): make selected-model routing strict and fallbacks explicit #5625.
• Backend policy: refactor(models): centralize explicit foreground fallback policy #5626 and draft PR refactor(model-routing): centralize explicit foreground fallback policy #5683.
• Strict-default behavior: Agent-mode tool-call rounds can resolve to a different model than the UI-selected one, causing unexpected API calls and rate-limit errors #4561 and draft PR fix(model-routing): keep user-selected models strict #5632.
• Implementation: draft PR feat(settings): add foreground fallback controls #5684.
• Feature Request: Separate model picker for Chat vs Agent mode #3151 separately proposes different Chat and Agent model pickers and is not part of this control.

Are you willing to implement this?

Yes — this is the third branch in the stacked series.