Add user-facing author and critic model selection

[akoita]

Goal

Allow a user to choose supported author and critic models instead of relying on workspace defaults or CLI-only overrides.

Scope

• provider-aware model catalog with availability/capability validation
• explicit economy/standard/premium presets with unvalidated quality labels
• visible input/output pricing and estimated run budget
• preserve provider-diversity warnings and exact model IDs in run history
• migrate existing workspaces only through an explicit user decision

This is active milestone 17 work. On 2026-09-30 the user approved retaining current defaults, delivering configurable recorded profiles, and separating representative CV-quality validation/default promotion into #683/#583. No automatic workspace migration or authentication change.

Ordered delivery

This is a rollup; execute bounded children with one observable outcome and one PR each.

• feat(desktop): change a workspace's author and critic models #536 — edit workspace model destinations in desktop.
• feat(desktop): derive unavailable-discovery suggestions from model profiles #678 — registry-derived unavailable-discovery suggestions.
• feat(cli): select exact model profiles or tier presets for new runs #684 — CLI exact profile pairs and tier preset selection (after feat(application): add opt-in frontier profile tiers and catalog metadata #682 catalog).
• feat(desktop): carry exact run profiles through the native bridge safely #685 — strict native profile forwarding and route support, binding starts to acknowledged destinations.
• feat(desktop): choose explicit profile pairs and tier presets for the next run #686 — explicit desktop next-run profile/preset picker.
• feat(desktop): disclose API rates and explicit profile budget estimates #687 — dated API rates and explicit estimated-budget scenarios.

#682 belongs to #511 and supplies the catalog shared by these adapters. Local synthetic availability/release checks stay #527/#679. Every profile is unvalidated for representative CV quality, and route support is not account availability.

[akoita]

Reframing after #95

#95 replaced company-based independence with model lineage (ADR 0005), which changes what this issue is for.

Two consequences:

The scope line "preserve provider-diversity warnings" is now the wrong concept. Independence is decided by lineage, not by company. A selector must prevent the author and critic from sharing a lineage, not merely a company — and it should surface the same override-with-recorded-rationale path the domain already implements, rather than a second, softer rule in the UI.

Choosing models by hand from memory is now the weak link. Model ids are typed as free text today (--author-model, --critic-model, and the workspace JSON). After #94 a local model id can be any arbitrary string, and after #95 the lineage attached to it decides whether the run is allowed at all. A typo silently produces a different lineage.

Added scope: dynamic discovery

List the models actually available to the configured credentials, instead of shipping a static catalog that goes stale:

• Anthropic, OpenAI, and OpenAI-compatible local servers all expose a models-list endpoint, so one capability covers all three. Local coverage matters most, because local model ids are arbitrary and unguessable.
• Discovery is a network call using the user's key, so it belongs in the main process behind a bridge command. Credentials must not reach the renderer (ADR 0004).
• It must degrade gracefully. This is a local-first product: a failed or offline discovery must not block workspace setup. Fall back to the last known list, and to free-text entry.

What discovery does not solve

Discovery returns model ids, not lineage. Rejecting "the same model" is trivial id equality; that is the shallow guarantee. The real one — "were these produced by the same weights?" — is unaffected, because two vendors serving one open-weights base model still return different ids.

That is the false-accept ADR 0005 describes, and it is closed by curated lineage defaults for known models, already listed as an ADR follow-up — not by discovery. A selector that blocks identical ids while silently permitting two aliases of one base model would restate the exact bug #95 removed, one layer up.

Pricing is likewise not discoverable from these endpoints and stays curated.

Suggested order

1. Curated lineage defaults for known models (ADR 0005 follow-up) — makes the constraint meaningful.
2. Discovery capability behind a bridge command, with caching and graceful degradation.
3. Selector UI that blocks a shared lineage and offers the recorded-rationale override.

Doing 3 before 1 ships a selector that enforces the shallow rule and looks authoritative while doing it.