Azure OpenAI / Foundry wired in as a third provider alongside Claude and Gemini

Commit 6de8751c introduces backend/src/lib/llm/azure.ts, a streaming/tool-loop adapter that follows the same interface as the Claude and Gemini drivers. Three env vars control which Azure deployment handles each tier: AZURE_OPENAI_MAIN_DEPLOYMENT, AZURE_OPENAI_TABULAR_DEPLOYMENT, and AZURE_OPENAI_TITLE_DEPLOYMENT. The frontend gets a new modelCatalog.ts that shows an "Azure" group in the model picker only when the matching NEXT_PUBLIC_AZURE_OPENAI_* deployment vars are set.

832920a9 revises the approach. The first cut used the AzureOpenAI SDK with an apiVersion query-param path; this commit drops that and switches to the plain OpenAI SDK pointed at Azure's /openai/v1/ endpoint, which mirrors the standard OpenAI API shape. AZURE_OPENAI_API_VERSION is removed entirely. The normalizer in azure.ts strips query strings and hashes, and case-insensitively rewrites any /openai or /openai/v1 suffix before appending the canonical path - so you can point AZURE_OPENAI_ENDPOINT at either the root resource URL or a full path and it will work.

ffad9905 is small but load-bearing. Next.js only inlines NEXT_PUBLIC_* vars when they're accessed as literal process.env.NAME expressions at build time. The original code passed the env var name as a string to a trimEnv(name) helper, which silently returned undefined in client bundles - meaning the Azure group never appeared in the picker. The fix reads each var directly and passes the resolved value into the label functions.

One behavioral caveat: models.ts resolves defaults via getDefaultMainModel(), and those helpers return an Azure deployment whenever the Azure env vars are present. That means deploying with Azure configured silently changes the default model for all users, even ones who haven't explicitly chosen it. Worth checking your deployment logic before adopting.