feat: add MetadataAddress support to ClientCredentialsClient for OIDC discovery

[paulomorgado]

Summary

This change adds MetadataAddress support to client-credentials token acquisition so callers can rely on discovery metadata instead of always hardcoding TokenEndpoint.

It aligns ClientCredentialsClient with established ASP.NET authentication configuration patterns while preserving full backward compatibility for existing TokenEndpoint-based setups.

Motivation

Today, ClientCredentialsClient requires TokenEndpoint up front. That makes configuration less flexible in environments where endpoint details are discovered dynamically from OpenID Connect metadata.

This PR enables that dynamic discovery flow by allowing MetadataAddress as an alternative configuration source.

What changed

1. Public API

   • Added Uri? MetadataAddress to ClientCredentialsClient.
   • Updated public API verification baseline accordingly.

2. Validation rules

   • Validation now requires:
     • ClientId, and
     • at least one of TokenEndpoint or MetadataAddress.
   • Improved validation error messages to explicitly indicate the missing requirement.

3. Runtime token endpoint resolution

   • In ClientCredentialsTokenClient, if TokenEndpoint is missing and MetadataAddress is provided, the token endpoint is resolved via discovery (GetDiscoveryDocumentAsync).
   • If discovery metadata does not provide a token endpoint, a clear InvalidOperationException is raised.
   • If both are configured, TokenEndpoint takes precedence.

Parallel with ASP.NET Core MetadataAddress semantics

This implementation intentionally mirrors the concept used by:

• OpenIdConnectOptions.MetadataAddress
• JwtBearerOptions.MetadataAddress

In both APIs, MetadataAddress is the discovery endpoint for obtaining metadata.
This PR brings the same model to client token management:

• Same idea: use discovery metadata as a source of authority configuration.
• Different use: OIDC/JWT bearer primarily bootstrap sign-in/validation metadata, while this client-credentials flow specifically needs discovery to resolve the token endpoint for token requests.

Behavioral notes

• Existing configurations using only TokenEndpoint continue to work unchanged.
• When both are set, TokenEndpoint is used directly (no discovery round-trip).
• A discovered token endpoint is reused for subsequent forced renewals, avoiding repeated metadata calls.
• Explicit metadata document URLs are honored as provided.

Test coverage added/updated

• Missing both TokenEndpoint and MetadataAddress throws.
• Missing TokenEndpoint + valid MetadataAddress discovers and requests token successfully.
• TokenEndpoint precedence over MetadataAddress.
• Metadata without token_endpoint throws expected exception.
• Metadata request failure path throws expected exception.
• Discovered token endpoint is reused.
• Explicit metadata document address is used as-is.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.