fix: route Azure embed requests through deployment endpoint

[rodboev]

Fixes #12554

Summary

Azure OpenAI embed requests can 404 because _getEmbedEndpoint checks apiType === "azure" while the Azure adapter sets apiType: "azure-openai". The strict check misses the Azure deployment route, so embed requests go to /embeddings instead of /openai/deployments/{deployment}/embeddings?api-version={version}. This change follows the Azure routing pattern already used by _getEndpoint for chat requests.

Root cause

core/llm/llms/OpenAI.ts:708 used strict equality for the embed endpoint, but Azure.ts:17 sets apiType: "azure-openai". The condition never matched, so Azure OpenAI embeddings skipped the deployment path. azure-foundry should still use the plain embeddings path, so the fix distinguishes azure and azure-openai from other Azure-flavored apiType values.

Changes

• core/llm/llms/OpenAI.ts: route azure and azure-openai embed requests through openai/deployments/{deployment}/embeddings, while keeping azure-foundry on the plain embeddings path
• core/llm/llms/OpenAI.vitest.ts: add coverage for both Azure OpenAI deployment routing and Azure Foundry plain-path routing
• core/llm/llms/OpenAI-compatible.vitest.ts: update the Azure subclass expectation to cover the deployment embed URL

Scope note

This PR no longer changes generic webview error logging. The related webviewProtocol.ts stringify guard is handled separately in #12589, so this branch stays focused on Azure embedding endpoint routing.

What this doesn't change

The chat/completions routing (_getEndpoint) and Responses API gate (canUseOpenAIResponses) are already correct for Azure and untouched. No model selection, parameter conversion, streaming logic, or generic webview error handling is modified.

Checklist

• I've read the contributing guide
• The relevant docs, if any, have been updated or created
• The relevant tests, if any, have been updated or created

Screen recording or screenshot

N/A, provider endpoint routing fix covered by tests.

Tests

Attempted locally: cd core && npx vitest run llm/llms/OpenAI.vitest.ts llm/llms/OpenAI-compatible.vitest.ts

Blocked before test collection because the local checkout is running Node v24.15.0 while .nvmrc requires v20.20.1, and sqlite3 has no native binding for the active Node version. The command failed with Could not locate the bindings file ... sqlite3 ... compiled\24.15.0\win32\x64\node_sqlite3.node.

[cubic-dev-ai]

No issues found across 3 files

_{Re-trigger cubic}