fix(provider): select Azure DeepSeek adapter

[IbrahimKhan12]

Issue for this PR

Closes#43106

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Azure DeepSeek deployments used the generic Azure chat or responses adapter. Select the dedicated deepseek() adapter when the API ID or model metadata identifies DeepSeek. Keep custom deployment IDs and existing routing for other Azure models.

Apply the same selection to the current Core provider path.

How did you verify your code works?

• packages/opencode: provider test file, 101 passed
• packages/core: Azure provider test file, 12 passed
• Repository-wide bun typecheck, 30 tasks passed

Screenshots / recordings

Not applicable. This is a provider routing change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[Enough1122]

AI code review — automated review for reference; please use your judgment.

• packages/core/src/plugin/provider/azure.ts:11 — The substring probe over id/name/family catches models literally named "deepseek-*" but not the common real-world case where the Azure DEPLOYMENT name omits the vendor ("ds-prod", "chat-reasoning-eu"), which silently re-selects the wrong adapter and reproduces the bug this fixes — consider an explicit escape hatch (a per-model providerOption like adapter: "deepseek") alongside the heuristic.
• packages/opencode/src/provider/provider.ts:154 — The matching logic is duplicated verbatim between this file and packages/core/src/plugin/provider/azure.ts (same four-field some/includes chain, same precedence before useChat); extracting a shared helper would prevent the two Azure paths from drifting the next time an adapter rule changes.
• packages/opencode/test/provider/provider.test.ts:812 — Both new tests exercise the happy path where sdk.deepseek exists; there is no case pinning behavior against an SDK build WITHOUT the deepseek export (older @ai-sdk/azure), which must fall through to chat/responses rather than throw — one assertion locks in the compatibility contract the sdk.deepseek guard implies.
• packages/core/src/plugin/provider/azure.ts:13 — When the model clearly is DeepSeek but the installed SDK lacks the deepseek adapter, the fallback is completely silent and the failure surfaces later as API-shape errors; a one-time warning naming the model and the missing adapter would turn a confusing runtime breakage into an actionable upgrade hint.

— AI code review (automated)

[Enough1122]

AI code review — automated review for reference; please use your judgment.

• packages/core/src/plugin/provider/azure.ts:12 — matching on [apiID, modelID, name, family].includes("deepseek") is a reasonable heuristic for named deployments, but it can misfire when a deployment serves a non-DeepSeek model under a DeepSeek-ish name (or vice versa). Since Azure deployments are user-named, consider allowing an explicit per-model option to force/skip the adapter as an escape hatch.
• Duplication: the same detection block is copy-pasted in packages/core/src/plugin/provider/azure.ts and packages/opencode/src/provider/provider.ts (selectAzureLanguageModel). These will drift; worth extracting into a shared helper if both stay.
• Ordering is right: DeepSeek check precedes chat/responses so useCompletionUrls doesn't shadow it — and the new test pins that exact precedence (deepseek:production-deployment with useCompletionUrls true).
• Good coverage at both the plugin unit level and the provider integration level.