OpenAI provider: detect Azure-shaped OPENAI_BASE_URL and append api-version

[rohitg00]

Why

#307 added the universal OpenAI-compatible provider and lists Azure OpenAI in its supported-endpoints table:

Azure OpenAI    https://{resource}.openai.azure.com/openai/deployments/{deployment}

But Azure OpenAI's /chat/completions requires:

1. An api-version=<YYYY-MM-DD> query parameter on every request (mandatory; the request 400s without it).
2. The api-key: <key> header instead of Authorization: Bearer <key> (Azure also accepts Bearer when AAD-auth is in use, but the api-key path is the default for key auth).

OpenAIProvider.call() today doesn't add either, so the Azure path in the supported-endpoints table is non-functional as-shipped.

Proposal

In src/providers/openai.ts:

private isAzure(): boolean {
  const url = this.baseURL ?? "";
  return url.includes("openai.azure.com") || url.includes("/openai/deployments/");
}

private buildRequestUrl(path: string): string {
  const base = this.baseURL ?? "https://api.openai.com";
  if (this.isAzure()) {
    const apiVersion = getEnvVar("AZURE_OPENAI_API_VERSION") ?? "2024-08-01-preview";
    return `${base}/chat/completions?api-version=${apiVersion}`;
  }
  return `${base}/v1/chat/completions`;
}

private buildHeaders(): HeadersInit {
  if (this.isAzure()) {
    return { "Content-Type": "application/json", "api-key": this.apiKey };
  }
  return { "Content-Type": "application/json", Authorization: `Bearer ${this.apiKey}` };
}

Note: Azure URLs already include the deployment path, so we append /chat/completions (no /v1/ segment).

Acceptance

• OPENAI_BASE_URL=https://<resource>.openai.azure.com/openai/deployments/<deployment> + OPENAI_API_KEY=<azure-key> round-trips a summarize call.
• AZURE_OPENAI_API_VERSION env var documented in README with the default GA value.
• Non-Azure base URLs (OpenAI, DeepSeek, SiliconFlow, Ollama, vLLM, LM Studio) unaffected — same code path, same Authorization: Bearer header.

Supersedes

• feat(providers): add Azure OpenAI provider #219 (dedicated Azure OpenAI provider) — closed as covered once this lands.

Out of scope

• AAD / managed-identity authentication (Bearer + Azure AD token). Key-auth only.
• Azure AI Foundry (Anthropic-API-on-Azure) — separate provider class via fix(providers): support Azure AI Foundry (Anthropic) endpoint and corporate proxy #220.

[rohitg00]

Shipped in v0.9.17 via PR #307 (universal OpenAI-compat provider).

Verified in src/providers/openai.ts:

• detectAzure(baseUrl) matches .openai.azure.com hostnames at construction time (src/providers/openai.ts:198-208).
• Azure URL builder appends api-version=<version> query param, drops the /v1/ prefix since deployment is in the path (src/providers/openai.ts:77-86).
• Azure header path uses api-key: <KEY> instead of Authorization: Bearer (src/providers/openai.ts:88-99).

Env var name shipped as OPENAI_API_VERSION (not AZURE_OPENAI_API_VERSION as proposed) — same key family as the rest of the OpenAI config block so users don't need to track a separate prefix. Default 2024-08-01-preview matches the spec.

Documented in README under the LLM Providers / Environment Variables section and in v0.9.17 release notes.