Support configuring Microsoft Entra ID as a Keycloak identity provider

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

The Keycloak roadmap in #1326 includes federation with Microsoft Entra ID, but there is no dedicated issue defining the expected Aspire experience. Today users must configure the Entra identity provider manually in Keycloak, embed it in realm configuration, or build custom provisioning logic.

The desired scope is unclear: this might require first-class integration API, declarative configuration support, documentation and a sample, or some combination of those.

### Describe the solution you'd like

Define and implement the supported experience for using Microsoft Entra ID as an identity provider for an Aspire-managed Keycloak instance.

The investigation should determine whether Aspire should provide dedicated API or instead document and test the scenario through the desired-state configuration mechanism tracked separately. Any resulting experience should:

- Keep Entra client credentials and secrets in Aspire parameters or publisher-native secret stores.
- Work with local development and have a documented production deployment path.
- Configure the correct Keycloak identity-provider endpoints and redirect URI.
- Include validation through documentation or a representative sample.

### Additional context

- Parent roadmap: #1326
- Keycloak desired-state configuration is tracked separately and may provide the implementation mechanism.
- Keycloak identity brokering documentation: https://www.keycloak.org/docs/latest/server_admin/#_identity_broker
- Microsoft Entra OpenID Connect documentation: https://learn.microsoft.com/entra/identity-platform/v2-protocols-oidc

Start with roadmap issue #1326 and the separately tracked Keycloak desired-state configuration work, then review the linked Keycloak identity brokering and Microsoft Entra OpenID Connect documentation. Determine whether the supported experience needs an API, declarative configuration, documentation, a sample, or a combination, and define validation for local development, production deployment, secrets, endpoints, and redirect URI.

Written by the indexing model from the issue text.