🤖 Fast mode toast: unknown model identity should give the route reason

[ThomasK33]

Problem: The fast mode shortcut toast (#5756) says "this model has no fast mode" when Xum cannot tell which model it is. This happens for an openai-compatible custom provider (for example one serving claude-opus-5-5) and for a Coder instance of unknown type. The claim can be false there. The route message ("on its current provider route ...") is never false in that case.

Fix idea: in getFastModeUnavailableReason (src/browser/utils/fastModeServiceTier.ts), return "route" when the capability identity is unknown. Flip the team-compat case in fastModeServiceTier.test.ts.

Priority P3. Size S. Follow-up of #5756 (found by its final check).

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

[ThomasK33]

One more case for this issue, found by the normal review of #5756 (thread: #5756 (comment)).

Copilot-hosted Claude models get the "model" reason instead of "route". A user on github-copilot:claude-opus-5-5 who presses the fast mode shortcut sees "this model has no fast mode". Direct Anthropic supports fast mode for Opus 5.5, so the real cause is that the Copilot route cannot send it.

Where: getFastModeUnavailableReason in src/browser/utils/fastModeServiceTier.ts:84 (on #5756 head 61fc4f5e21). normalizeToCanonical keeps the github-copilot: prefix, because that gateway has no canonicalizer. The direct-provider check then rejects the model.

Scratch-script evidence (on that head, providersConfig = null):

github-copilot:claude-opus-5-5 model
anthropic:claude-opus-5-5 route
anthropic:claude-haiku-4-5 model

The fix belongs with the other identity cases here: map Copilot's recognizable upstream model family before the direct-provider check. The user approved deferring it from #5756 to this issue.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high