feat: add azure-foundry provider for Microsoft Foundry model access

Summary

Add a first-class azure-foundry provider type so Kimi Code can connect to Microsoft Foundry deployments without hand-wiring the generic openai provider.

Foundry hosts many model families (OpenAI GPT, DeepSeek, Meta Llama, Mistral, Cohere, and others sold directly by Azure — not just OpenAI). A dedicated provider name reflects that breadth and gives us a single place to handle Foundry-specific auth, endpoints, and model routing — rather than overloading openai.

Motivation

Today there is no Azure / Foundry provider in kimi-code:

• Provider types are limited to anthropic, openai, kimi, google-genai, openai_responses, and vertexai (see packages/agent-core/src/config/schema.ts).
• No Foundry entry in the models.dev catalog, so /provider cannot import it.
• No documentation for Foundry setup.

Users are already working around this manually. #520 reports a real session using Azure AI Foundry with:

[providers.azure]
type = "openai"
base_url = "https://[resource].openai.azure.com/openai/v1"
api_key = "[API_KEY]"

That proves demand, but it is undocumented, untested, and fragile — especially around auth (api-key header vs Bearer) and thinking-model behavior after tool calls.

Proposed design

Provider type: azure-foundry

[providers.my-foundry]
type = "azure-foundry"
base_url = "https://YOUR-RESOURCE.openai.azure.com/openai/v1"
api_key = "YOUR_KEY"

[models.foundry-gpt4o]
provider = "my-foundry"
model = "gpt-4o"
max_context_size = 128000

Credential env keys (proposed): AZURE_FOUNDRY_API_KEY, AZURE_FOUNDRY_BASE_URL.

Why not reuse openai?

Concern	openai reuse	azure-foundry
Naming	Implies OpenAI-only	Matches Foundry’s multi-model catalog
Auth	SDK sends Authorization: Bearer; Foundry expects api-key (or Entra Bearer) per integration docs	Foundry-specific auth in one adapter
Endpoints	User must know v1 vs legacy deployment URL shapes	Provider documents and validates Foundry endpoint patterns
Future models	Claude / Mistral / etc. on Foundry need different wires	Natural extension point to route by model family

Implementation can still delegate to existing kosong wires (openai, anthropic, …) internally — the new type is the Foundry-facing config surface, not a full protocol rewrite.

Integration surface (per Microsoft docs)

Foundry exposes several endpoint families. For kimi-code’s agent loop, the initial target should be the OpenAI v1-compatible route:

POST https://{resource}.openai.azure.com/openai/v1/chat/completions

Auth headers (either):

• api-key: {your-key} (API key — primary v1 path)
• Authorization: Bearer {entra-token} (Entra ID)

Microsoft recommends this route for third-party SDKs and deprecates the old Inference API (services.ai.azure.com/models, retiring May 2026). See Integrate Microsoft Foundry with your applications.

Proposed scope (v1)

• Add azure-foundry to provider schema, TOML parsing, and provider-manager
• Kosong adapter: Foundry auth (api-key header), correct base URL handling for v1 route
• Reuse OpenAI chat-completions streaming/tools/reasoning path under the hood
• Document setup in docs/en/configuration/providers.md and Chinese mirror
• Unit tests for auth header construction and provider config resolution
• Changeset (minor — new provider type)

Out of scope (follow-up issues)

• Foundry Agent Service / project APIs (services.ai.azure.com/api/projects/...)
• Entra ID token refresh / managed identity
• Legacy deployment URLs (/openai/deployments/{id}/chat/completions?api-version=...)
• Non-OpenAI model families on Foundry (e.g. Claude, Mistral) — architecture should allow routing to the right wire later, but not required for v1
• /provider catalog import (models.dev has no Azure/Foundry entry today)
• Reasoning-only completion after tool calls on Foundry (#520) — related bug, separate fix

Open questions for maintainers

1. azure-foundry vs azure_foundry in TOML — repo mixes google-genai (kebab) and openai_responses (snake). Preference?
2. v1-only for first PR, with legacy deployment URL support as a follow-up?
3. Should v1 also expose an openai_responses sub-path for Foundry models that use the Responses API?

Acceptance criteria

• User can configure an azure-foundry provider pointing at a Foundry v1 endpoint and run a basic chat turn with tools.
• api-key authentication works without Bearer-header hacks.
• Documented example config in both locales.
• No regression to existing openai provider behavior.

Start with packages/agent-core/src/config/schema.ts and the provider-manager entry point, then trace the existing OpenAI provider path and its configuration tests. Review docs/en/configuration/providers.md and the Chinese mirror for the documented examples. Done means a v1 Foundry provider supports api-key authentication, chat with tools, tests cover auth and config resolution, both locales are documented, and existing OpenAI behavior is unchanged.