Fleet models: provider → model → shortlist → role, with save-in-role and a fleet-aware operator

## Founder direction (2026-09-06)

> we still need to make it so we are making like a shortlist of models that the user wants to be considered for sub agents — the flow from provider → model → model shortlist (that becomes the fleet models for the operator to choose from and assign roles, and then a user can choose if they want to save that model in that role) — and we want that + the manual configuration.

Plus the standing goals this serves: truly model-agnostic, cache-maxxing, and the working model being aware of every model in its fleet.

## What exists today (receipts)

- Fleet profiles already persist a provider, model, and thinking setting per role (#4137, #5042), and `roster.model_overrides()` plus `config.subagent_model_overrides()` are merged into the subagent runtime's `role_models` at launch (`crates/tui/src/lib.rs` ~11964, `tools/subagent/mod.rs` ~12914).
- `[subagents] providers.` carries per-provider fan-out and budget knobs (`config.rs` ~2725) but no model list.
- The spawn `model` parameter is validated per provider (`normalize_requested_subagent_model`) but the operator is never told which concrete models it may pick; the prompt only documents `model_strength`.
- The model picker shows the live catalog per provider; there is no "consider this for the fleet" mark, so the only way to a role→model binding is editing a Fleet profile or TOML.

## Proposed flow

1. **Provider** — connected providers (exists).
2. **Model** — the live catalog for that provider (exists).
3. **Shortlist** (new) — in the model picker, a one-key toggle marks a model "fleet". Persisted as `[fleet] models = ["provider/model", ...]` in config; the same list is editable by hand. Entries are `provider/model` ids resolved through the model registry, so nothing is provider-specific.
4. **Roles** (extend) — at spawn time the operator sees the shortlist as *fleet models* and assigns one per role; the `model` parameter is constrained to the shortlist (plus the session model) and the error for an off-list model names the list. In the Agents view, a role row offers "save this model in this role", which writes the existing Fleet profile — no second store.
5. **Manual configuration** stays authoritative: `[subagents.roles.] model = "provider/model"` and Fleet profiles win over the shortlist; the shortlist is what the operator may choose from when nothing is pinned.

## Operator awareness and cache

- The subagent tool description (or a stable system-prompt block) lists the fleet models with the tags the registry already knows: strength tier, context window, price class, and whether the route is currently reachable. Stable ordering, rebuilt only when the shortlist or a pin changes, so the block is prefix-cache friendly.
- When the shortlist is empty the block says so and the operator falls back to today's `model_strength` behaviour.

## Acceptance

- Toggle a model in the picker → it appears in `[fleet] models` and in `/fleet` as a fleet model; remove it → it disappears from both.
- Operator spawn with a shortlisted model succeeds on any provider; an off-list model is refused with the list in the message.
- "Save in role" from the Agents view produces the same Fleet profile a manual TOML edit would, and the next session spawns that role on that model without the operator choosing.
- The operator prompt/tool description shows every fleet model with its tags; snapshot test pins the block and its ordering.
- Narrow terminal and localized labels covered like the rest of the picker.

## Out of scope

Automatic model routing or pricing decisions (`--model auto` stays as is); provider onboarding; any change to how a single-session model is chosen.

Start by tracing fleet role models and subagent runtime merging in crates/tui/src/lib.rs and tools/subagent/mod.rs, then inspect provider configuration and model validation in config.rs. Map the model picker, registry metadata, Agents view, and Fleet profile paths against the proposed shortlist flow; done means the listed acceptance cases pass, including persistence, validation, prompt tags, snapshots, narrow terminals, and localization.

Written by the indexing model from the issue text.