Interactive OAuth sign-in for Azure AI providers without Azure CLI

**What problem would this solve?**

Azure OpenAI and Azure AI Foundry support Microsoft Entra bearer tokens, but goose's end-user path currently expects either a pre-acquired token or an Azure CLI session (`az login` / `az account get-access-token`). Azure CLI is reasonable for developers and automation, but it is not an accessible sign-in experience for many desktop and CLI users. Static Entra tokens also expire quickly and do not provide an integrated refresh or sign-out experience.

This affects organizations that want employees to access an Azure AI Foundry project with their individual Entra identity, MFA, Conditional Access, and Azure RBAC instead of distributing API keys or requiring developer tooling. The same architectural question may later apply to OpenAI-compatible enterprise gateways protected by OAuth/OIDC.

**What would a good outcome look like?**

A user can select an interactive authentication method for a supported provider, sign in through their organization's identity provider without installing Azure CLI, and have goose securely refresh and store credentials.

For an initial Azure AI Foundry outcome:

- a public Entra client can be configured with tenant and client IDs;
- no client secret is embedded or requested;
- a local desktop user can authenticate interactively;
- a headless or remote CLI user has a Device Code option;
- access and refresh credentials use goose's existing secure secret storage;
- the bearer token is attached through the existing `AuthProvider` / `ApiClient` path;
- API key, static bearer token, and Azure CLI workflows remain available;
- users receive actionable errors that distinguish Entra app permissions/consent from Azure RBAC failures;
- login status and sign-out can eventually be exposed consistently in CLI and desktop provider setup.

**Possible approaches**

There are two design scopes to discuss.

1. **Azure-first implementation**
- Add Microsoft Entra Authorization Code + PKCE for desktop/local usage.
- Use OAuth 2.0 Device Authorization Grant for CLI/headless usage.
- Request endpoint-specific scopes:
- Foundry project/resource: `https://ai.azure.com/.default`
- Foundry MaaS: `https://ml.azure.com/.default`
- Azure OpenAI: `https://cognitiveservices.azure.com/.default`
- Keep Azure CLI as an explicit advanced fallback.

2. **Generic OAuth bearer-token infrastructure first**
- Extract configurable authorization, token, and device endpoints; client ID; scopes; refresh; and secure persistence.
- Add Entra as the first preset, with possible future presets for Google or custom OIDC gateways.
- Keep AWS outside this abstraction where SigV4 and temporary AWS credentials are required rather than a bearer token.

Existing goose components that could be reused include:

- the RFC 8628 helper in `oauth_device_flow.rs`;
- `AuthMethod::Custom` and the `AuthProvider` trait in `ApiClient`;
- `GooseCredentialStore` / `Config` secret storage;
- existing browser OAuth, PKCE, callback, refresh, and provider setup patterns.

Design questions for maintainers:

- Should the first supported path be Azure-specific or should generic OAuth configuration be introduced first?
- Should desktop default to Authorization Code + PKCE and CLI/headless default to Device Code?
- Should interactive auth be part of provider metadata/configuration or a separate authentication-profile model?
- How should authenticate/status/logout be represented through provider setup and ACP?
- Should Azure CLI remain an implicit fallback or become an explicit authentication choice?
- Should existing provider-specific OAuth token caches be migrated as part of this work or separately?

**Additional context**

A draft proof of concept exists in #11371. It reuses the shared Device Code helper for Azure AI Foundry and validates the internal integration points, but it is intentionally WIP and should not be considered the agreed design.

A live request reached Microsoft Entra and produced a device code. Token issuance then returned `AADSTS650057` because the test app registration only allowed Microsoft Graph and did not yet have the delegated permission for `https://ai.azure.com`. This confirmed an important deployment requirement: Entra delegated API permissions and consent are separate from the signed-in user's Azure RBAC assignment on the Foundry resource.

The proof of concept is Azure/Entra-specific. It does not currently provide generic GCP, AWS, Scaleway, or custom-provider authentication.

- [x] I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).