Pin OIDC sign-in Authority precedence (parity with MSAL conflict tests)

[iarekk]

Add 17 pinning tests for the OIDC sign-in code path with parity to the MSAL conflict suite.

Description

MergedOptionsAuthorityConflictTests covers the MSAL token-acquisition path when Authority is configured alongside Instance, TenantId, Domain, or SignUpSignInPolicyId. There is currently no equivalent coverage for the OIDC sign-in path in MicrosoftIdentityWebAppAuthenticationBuilderExtensions, and the two paths exhibit different precedence and logging semantics today:

Scenario	Token-acquisition (MergedOptions.ParseAuthorityIfNecessary)	OIDC sign-in (AddMicrosoftIdentityWebApp -> Configure<OpenIdConnectOptions>)
Authority + Instance/TenantId/both	Instance+TenantId win; Authority ignored; logs AuthorityIgnored (EventId 500)	Authority wins verbatim; Instance/TenantId are dead config; no warning
Authority only	Parses Authority into Instance+TenantId; logs AuthorityUsedConsiderInstanceTenantId (EventId 501)	Propagates Authority verbatim (after EnsureAuthorityIsV2); no parsing, no hint
Instance+TenantId only	No warning; values unchanged	AuthorityHelpers.BuildAuthority composes Instance/TenantId/v2.0

This divergence is observable to library users and isn't documented anywhere we can find. The downstream docs (and PR #3617) describe the Instance+TenantId-wins precedence as if it were universal, but it only holds for the token-acquisition path.

When each code path runs in a sample app

A typical ASP.NET Core web app that signs users in and calls a downstream API exercises both paths -- but at different times.

OIDC sign-in path (Authority wins, no warning)

Triggered on every sign-in challenge by the ASP.NET Core authentication middleware.

Program.cs
  services.AddAuthentication(...)
        .AddMicrosoftIdentityWebApp(config, "AzureAd", ...)   // registers Configure<OpenIdConnectOptions>
        .EnableTokenAcquisitionToCallDownstreamApi(...)
        .AddInMemoryTokenCaches();

Request to a [Authorize] action
  AuthenticationMiddleware
   -> CookieAuthenticationHandler  (no auth cookie)
   -> OpenIdConnectHandler.HandleChallengeAsync
       -> IOptionsMonitor<OpenIdConnectOptions>.Get(scheme)
           -> runs the Configure<OpenIdConnectOptions> callback registered by
              MicrosoftIdentityWebAppAuthenticationBuilderExtensions
              (src/Microsoft.Identity.Web/WebAppExtensions/MicrosoftIdentityWebAppAuthenticationBuilderExtensions.cs:310)
               -> if mergedOptions.Authority != null:
                      AuthorityHelpers.GetAuthorityWithoutQueryIfNeeded
                      AuthorityHelpers.BuildCiamAuthorityIfNeeded
                      PopulateOpenIdOptionsFromMergedOptions    // options.Authority <- mergedOptions.Authority
                  // else (Authority blank): options.Authority = AuthorityHelpers.BuildAuthority(mergedOptions)
                  options.Authority = AuthorityHelpers.EnsureAuthorityIsV2(options.Authority)
       -> redirect to options.Authority/oauth2/v2.0/authorize

No call to ParseAuthorityIfNecessary anywhere on this path; no EventId 500 / 501 ever fires.

MSAL token-acquisition path (Instance+TenantId wins, EventId 500 logged on conflict)

Triggered later, only when the app actually asks for an access token.

Controller action
  await _tokenAcquisition.GetAccessTokenForUserAsync(scopes)
   (or via _downstreamApi.CallApiForUserAsync(...))
   -> TokenAcquisition.GetAuthenticationResultForUserAsync
       (src/Microsoft.Identity.Web.TokenAcquisition/TokenAcquisition.cs)
       -> _tokenAcquisitionHost.GetOptions(scheme, out _)
           -> TokenAcquisitionAspnetCoreHost.GetOptions
              (src/Microsoft.Identity.Web.TokenAcquisition/AspNetCore/TokenAcquisitionAspnetCoreHost.cs:54)
               -> _mergedOptionsMonitor.Get(scheme)
               -> MergedOptions.ParseAuthorityIfNecessary(mergedOptions)   // <-- the only call site
                   - if Authority AND (Instance OR TenantId) configured:
                       overwrites mergedOptions.Authority with Instance/TenantId/v2.0
                       logs MergedOptionsLogging.AuthorityIgnored (EventId 500)
                   - if Authority only:
                       parses Authority into mergedOptions.Instance + TenantId
                       logs AuthorityUsedConsiderInstanceTenantId (EventId 501)
       -> GetOrBuildConfidentialClientApplicationAsync(mergedOptions)
           -> ConfidentialClientApplicationBuilder.WithAuthority(mergedOptions.Authority)

ParseAuthorityIfNecessary is called from three hosts in the same way: TokenAcquisitionAspnetCoreHost.cs:61, DefaultTokenAcquisitionHost.cs:54, and OwinTokenAcquisitionHost.cs:56.

Net effect

For an app configured with both Authority and Instance+TenantId:

• Sign-in goes to the IdP encoded in Authority (OIDC path).
• The downstream-API token is requested from the IdP encoded in Instance+TenantId (MSAL path) -- silently, with EventId 500 in the logs only if you have Information-level logging enabled.

If those two values disagree, the user signs in against one tenant and gets tokens for another. That mismatch is what these tests pin.

What this PR adds

A single new test class WebAppExtensionsAuthorityConflictTests (455 lines, 17 tests) covering:

• AAD precedence (5): Authority+Instance, Authority+TenantId, Authority+both, Authority-only (control), Instance+TenantId-only (control)
• B2C precedence (2): Authority+Instance+Domain+SignUpSignInPolicyId conflict, plus Instance+Domain+UserFlow composition control
• CIAM precedence (2): Authority+Instance conflict, plus Authority-only-through-BuildCiamAuthorityIfNeeded control
• Log assertions (7): explicit DoesNotContain(EventId.Id == 500) / == 501 checks for each conflict scenario across AAD/B2C/CIAM -- the strongest single piece of evidence that the divergence is real
• Robustness (1): mirrors MSAL's NoLogger_NoException -- builds a ServiceProvider with no AddLogging() registered and asserts no exception

Every test carries a comment of one of three shapes so the file can be skim-reviewed against the MSAL suite:

• // MSAL parity: <MethodName>. Divergence: ... (11 tests)
• // MSAL parity: <MethodName>. Same outcome on both paths. (3 control / robustness tests)
• // No MSAL counterpart; ... (the 2 OIDC-only tests)