feat(azure-auth): native AAD support for azure_ai/* targets (Foundry hosted agents)

[tangym]

Summary

Adds native AAD support for Azure AI Foundry hosted agents (and other azure_ai/* LiteLLM routes), so users can point target.model at azure_ai/agents/<asst_id> and have it just work with az login / managed identity / service principal, the same way azure/* models already do.

Problem

target.model: azure_ai/agents/<id> was technically reachable via LiteLLM, but the existing AAD wiring only injected tokens for azure/* models. Users hit two confusing dead ends:

1. AZURE_API_KEY (Azure OpenAI) silently suppressed AAD injection for azure_ai/* calls because mode resolution was global. With a key set for orchestration (azure/gpt-4o-mini systematize/tester/judge), the Foundry call also entered key mode and was sent to Foundry without a bearer token, returning a misleading 'no api_key' error.
2. LiteLLM's missing-api_base error was misclassified as retryable, so the eval burned 5 retries before surfacing the real cause.

Changes

File	Change
assert_ai/core/azure_auth.py	Add AZURE_FOUNDRY_SCOPE. Per-scope get_azure_token_provider(scope=...) cache that shares one DefaultAzureCredential. Family-aware resolve_azure_auth_mode(family=...) that checks AZURE_API_KEY for the azure family and AZURE_AI_API_KEY for the azure_ai family. Broaden boot-log label to Azure auth mode: since it covers both families.
assert_ai/core/model_client.py	New _aad_scope_for_model() dispatch. Inject AAD credentials for both Azure families: azure/* keeps azure_ad_token_provider callable, azure_ai/* calls the provider once per request and stuffs the bearer into payload['api_key'] (what LiteLLM's azure_ai/agents provider expects). Re-resolve mode per family on azure_ai/* injection to avoid the AZURE_API_KEY leak. Classifier widened so 401s and missing-token/AZURE_AI_API_BASE errors on azure_ai/* surface actionable hints instead of generic retryable errors.
assert_ai/core/config_model.py	Reject target.tools and target.system_prompt on azure_ai/agents/* (the hosted agent owns its tools and instructions server-side).
docs/getting-started.md, docs/config/schema.md	Two-line addendum noting Foundry agents share the same auth setup; new schema bullet for azure_ai/agents/<AGENT_ID>.
tests	+8 tests: per-scope cache, family-aware resolver, env-isolation regression for the AZURE_API_KEY leak, both LiteLLM api_base error variants, hosted-agent validation guards.

Commits (6, each independently green)

SHA	Subject
924eced5	feat(azure-auth): per-scope token-provider cache for azure_ai/* support
4b3f91b0	feat(model_client): inject AAD credentials for azure_ai/* models
a2699d23	feat(model_client): friendly error hints for azure_ai/* failures
4429314d	chore(azure-auth): broaden boot-log label to cover azure_ai/* family
7b23b57a	feat(config): reject target.tools and system_prompt on azure_ai/agents/*
1f97de8d	docs(azure-auth): note azure_ai/* (Foundry agents) shares the same auth

User-visible change

Before this PR, the only paths to a hosted Foundry agent were a callable wrapper or a manually-minted AZURE_AI_API_KEY=$(az account get-access-token ...). After this PR, point target.model at the agent and ASSERT mints the AAD token for you:

pipeline:
  inference:
    target:
      model:
        name: azure_ai/agents/asst_xxx

pip install -e ".[azure-aad]"
az login
export AZURE_AI_API_BASE=https://<resource>.services.ai.azure.com/api/projects/<project>
assert-ai run --config <your_config>.yaml

Service Principal (AZURE_TENANT_ID / AZURE_CLIENT_ID / AZURE_CLIENT_SECRET) and managed identity flow through the same DefaultAzureCredential chain.

Testing

• Full suite: 1113 passed, 17 skipped, 1 deselected (docker-env test unrelated).
• Each commit green standalone (rebase-friendly history).
• End-to-end smoke-tested against a real Foundry-hosted Assistant: AAD token minted with https://ai.azure.com/.default scope, injected into payload['api_key'], request reached the Foundry endpoint, server-side run completed, reply returned correctly.

Out of scope

• v2 Foundry Agents (UUID IDs at {project}/agents/{uuid}/threads/...). LiteLLM's azure_ai/agents provider only speaks the v1 Assistants surface (asst_xxx) and rejects UUIDs with Invalid 'assistant_id': '<uuid>'. Expected an ID that begins with 'asst'. v2 agents are evaluable today via the callable-wrapper path demonstrated in Add LangGraph Foundry hosted-agent example with Adaptive Eval #250. A native v2 target will be tracked in a separate issue.
• OTel trace visibility for hosted Foundry agents. Foundry server-side traces would need a separate export integration; out of scope here.

Related

• Add LangGraph Foundry hosted-agent example with Adaptive Eval #250 — community-contributed callable-wrapper example for hosted Foundry agents. Complementary path: use that example's pattern when you need a Python entrypoint with full OTel visibility, or when targeting v2 agents.