Problem

A legacy session can still keep an old explicit provider hint in its stored model, for example:

@copilot:gpt-5.5

If the user's current active provider is now openai-codex and Copilot is no longer routable/visible, chat startup can keep targeting the stale provider hint instead of recovering to the current provider/default model. Locally this showed up as an old session playing the notification sound but not displaying the assistant reply until the stored model was manually changed to the bare model (gpt-5.5).

Relationship to earlier work

This is the same family as #1023, but it is a residual path rather than a duplicate of the already-fixed case.

#1023 / #1029 covered stale bare and slash-prefixed session models, for example provider/model strings such as openai/gpt-5.4-mini after provider changes.

This issue covers the explicit dropdown routing format:

@provider:model

That format is valid for cross-provider dropdown routing, so the fix should not blindly strip every @provider: prefix.

Expected behavior

The session model compatibility layer should handle @provider:model with these rules:

1. If the provider hint matches the current active provider, normalize to the bare model.
2. If the provider hint is still routable in the current model catalog, preserve it.
3. If the provider hint is no longer routable, recover to the current active provider family or the current default model.
4. Keep the existing slash-prefixed model behavior from bug(sessions): stale session model not normalized for non-standard providers (ollama, deepseek, xai) — sessions stay broken after fixing default model #1023 unchanged.

Proposed PR scope

A narrow bugfix PR should update the session model compatibility layer only:

• parse persisted @provider:model session values in _resolve_compatible_session_model()
• preserve still-routable non-active provider hints
• normalize stale/unroutable hints before chat startup
• add regression tests for stale Copilot hints, active-provider hints, routable cross-provider hints, and mismatched provider families

No UI change or bulk migration is needed for this issue.