research(models): make saved-selector fallback route-aware

Problem

Startup model-selection reconciliation currently treats the configured provider ID as the availability boundary. If the provider is absent from a ModelsMsg, reconcileSelection clears the saved selection and falls back to the server default for that run.

That is not a reliable availability signal for routed providers and proxies:

• OpenRouter exposes downstream inference providers behind one wire adapter/provider ID.
• OpenAI-compatible or other proxy endpoints may route one configured provider/model selector to multiple upstream providers.
• A catalog snapshot can omit a provider/model while the endpoint can still serve the selector, or present a provider row whose downstream route cannot serve the selector.

The current fallback can silently replace an intentional routing choice with the server default before the server is allowed to evaluate it.

Relevant current behavior:

• cmd/mecatui/ui/models.go (reconcileSelection) clears a non-zero selection when no catalog row shares its ProviderID.
• The code intentionally retains a selection when its provider exists but its exact model is absent, because the server is authoritative for model validation.
• That provider-level distinction is insufficient for routed/proxied deployments.

Research questions

1. What does a client.ModelSelection.ProviderID mean for each adapter type: wire adapter, configured endpoint, OpenRouter downstream preference, or another identity?
2. Which available signals are authoritative for whether a requested selector can be served: live model catalog, provider capability metadata, endpoint response, or explicit route configuration?
3. Should startup always send the persisted selector to the server and rely on a precise server rejection, or is there a safe local preflight for some provider classes?
4. If fallback remains appropriate, how can it be explicit and truthful about route/proxy semantics rather than treating a missing provider row as a removed API key?
5. How should the picker, provenance line, and fallback warning represent a selector whose serving provider is indirect or route-dependent?

Acceptance

• Document a provider/route identity model that covers direct providers, OpenRouter downstream routing, and OpenAI-compatible/proxy endpoints.
• Make startup reconciliation and fallback follow that model rather than relying solely on ProviderID presence in a catalog snapshot.
• Preserve a user-selected selector unless there is authoritative evidence it cannot be served.
• On an actual failure, surface an actionable, accurate message that identifies the requested selector and the relevant serving/routing context without leaking credentials.
• Add offline regression coverage for at least one routed/proxy scenario and one ordinary direct-provider scenario.

Start with cmd/mecatui/ui/models.go and reconcileSelection, then trace client.ModelSelection.ProviderID through the adapter and catalog paths. Compare direct-provider behavior with OpenRouter and OpenAI-compatible/proxy flows, and identify the offline test entry points for model selection. Done means the provider/route identity is documented, reconciliation preserves valid persisted selectors, failures are actionable without credentials, and regression coverage covers routed and direct cases.