design(providers): cloud-native auth for Azure AI Foundry (Entra ID) and Amazon Bedrock (SigV4 / IAM Identity Center) #6072

Follow-up from #6031. The API-key connections for Azure AI Foundry and Amazon Bedrock (#6032) deliberately cover only key-based access. This issue tracks the cloud-native authentication those entries do not provide, which #860 left out of the initial provider scope because it needs its own product design.

Scope

• Azure AI Foundry: Microsoft Entra ID. Token acquisition and refresh, tenant/project selection, and how a Foundry project endpoint (rather than the /openai/v1 or /anthropic resource endpoint) is configured.
• Amazon Bedrock: AWS credentials. SigV4 signing from the standard credential chain (profiles, environment, SSO cache), region selection, and IAM Identity Center sign-in.
  • feat(provider): add Amazon Bedrock IAM Identity Center SSO #3370 (keyuchen21) proposed IAM Identity Center for Bedrock under the amazon-bedrock provider id with an aws_sso credential kind. It was closed by the stale bot on 2026-10-07 for inactivity, not rejected. Reviving or rescoping it is the natural starting point.
  • The API-key entry from feat(providers): add Azure Foundry and Bedrock API-key connections #6032 uses a separate id, amazon-bedrock-api-key, so it does not collide with amazon-bedrock.

Open design questions

1. One provider entry per cloud with a credential-kind choice, or separate entries per auth method, given that feat(providers): add Azure Foundry and Bedrock API-key connections #6032 already ships an API-key entry?
2. Where credentials and refresh live: Desktop main, the Runtime Host, or the CLI. This includes how a remote (SSH) Runtime Host gets them.
3. What happens to an existing API-key connection if the same provider later gains a cloud-native credential kind (migration or coexistence)?

Refs #860, #3370, #6031, #6032.