Default model choice fails when org policy loads model list after copilot load

Describe the bug

What's happening: ┃
┃
• Your user default is correctly saved ( ~/.copilot/settings.json  →  "model": "GPT-5.6 Sol" ). ┃
• At session startup, the resolver checks GPT-5.6-Sol against the model catalog it has at that instant — only ~150-400ms after auth completes — and doesn't find it ┃
available yet, so it silently falls back to  claude-sonnet-5 . ┃
• This happens before any managed/org policy is even involved (the policy log lines only cover telemetry/bypass permissions, not model allowlists) — so it's not an org ┃
restriction blocking the model. ┃
• The UI briefly shows "Sol" (from your saved default) before the resolver's fallback takes effect and the display corrects to Sonnet — matching exactly what you saw. ┃
┃
This looks like a timing/race condition: the model entitlement/catalog fetch for GPT-5.6-Sol on your account hasn't completed (or propagated) by the time the session binds ┃
its model, so it can't find it in the "available" list yet.

Affected version

No response

Steps to reproduce the behavior

in org with policy-configured model list, slect a policy-avaiable model (not default available model) as default via /config or /settings, then restart copilot, it will show the new model briefly, before defautling back to a differnet model

Expected behavior

expect it to respect the configured default model.

Additional context

No response

Reproduce the issue by selecting a policy-available model through /config or /settings, then restarting Copilot in an organization with a configured model list. Trace startup model resolution against catalog loading; done means the configured default remains selected after startup instead of briefly appearing and falling back to another model.