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
• recommended quality/cost presets
• 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 intentionally lower priority than completing the v0.6 validation gate and application-grade v0.7 workflow.

[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.