docs: add Azure AI Foundry v1 Entra guide

[cb-117]

Summary

• add a dedicated Azure AI Foundry OpenAI-compatible v1 guide for Entra ID authentication
• document when to use /openai/v1 versus classic Azure deployment/API-version configuration
• link the new guide from the existing Azure OpenAI with EntraID overview

Validation

• npm run prettier:check
• npm run build
• git diff --check

Notes: npm run build passes with an existing broken-anchor warning outside this change (/features/extensibility/plugin/functions/filter#filter-administration--configuration). npm run mdx-check could not complete because docusaurus-mdx-checker is not declared in package dependencies and npx attempted to fetch it from npm.

[Classic298]

Thanks for putting this together. Closing because two central claims do not match the current backend, so the guide as written would lead users into a broken configuration.

1. Model discovery via /models does not happen for Azure connections. With azure: true, routers/openai.py get_models returns whatever is in model_ids and makes no remote call. Telling admins to "leave Model IDs empty" produces an empty model picker, not discovered models. The "Supports OpenAI-compatible /models discovery" bullet and the comparison-table "Model source" row describe behaviour the code does not implement for the Azure provider.

2. Verify Connection is not v1-aware. verify_connection always builds {url}/openai/models?api-version=..., so a /openai/v1 base URL produces a malformed .../openai/v1/openai/models?... request. The four other Azure call sites (chat completion, responses, proxy, request-time api-version header) already detect v1 via re.search(r'/openai/v1(?:/|$)', url). verify_connection is the lone holdout.

The Entra ID, AZURE_TOKEN_CREDENTIALS and RBAC content is accurate, and chat itself does work over a Foundry v1 URL once Model IDs are populated by hand. Path forward is either:

• a revision that drops the /models-discovery framing, tells admins to enumerate Model IDs manually, and notes that Verify Connection currently fails on Foundry v1 URLs until the backend gets the same is_azure_v1 branch; or
• a paired backend change that adds the v1 branch to verify_connection and makes get_models honor v1 by calling {url}/models, after which the guide as written becomes accurate.

Happy to merge either revision.