Throw on Authority vs Instance/TenantId conflict (OIDC + MSAL parity)

[iarekk]

Summary

Replaces the silent EventId 500 warning with InvalidOperationException when both Authority and Instance/TenantId are explicitly configured. Both the OIDC sign-in path and the MSAL token-acquisition path now throw the same exception, resolving the behavioral divergence documented in the pinning tests (#3855).

Problem

Previously, configuring both Authority and Instance/TenantId produced different outcomes depending on the code path:

• MSAL path (ParseAuthorityIfNecessary): logged a warning (EventId 500) and silently ignored Authority
• OIDC path (OpenIdConnect middleware): silently honored Authority

Neither path surfaced the conflict to the developer at startup time.

Solution

Dual-latch provenance tracking on MergedOptions

Two latch properties track whether Authority and Instance/TenantId came from user config vs internal derivation:

• AuthorityExplicitlyConfigured -- set when Authority is written from user config (MicrosoftIdentityOptions or JwtBearerOptions), NOT when backfilled by MicrosoftEntraApplicationOptions computed getter
• InstanceOrTenantIdExplicitlyConfigured -- set when Instance or TenantId is written from user config (MicrosoftIdentityOptions or ConfidentialClientApplicationOptions), NOT when derived by ParseAuthorityIfNecessary or the computed Authority getter

Both latches use a set-only pattern (once true, never reverts to false).

Conflict detection

• ThrowIfAuthorityConflict() helper on MergedOptions -- throws InvalidOperationException only when both latches are set and both sides are populated. Shared by MSAL and OIDC paths.
• _authorityParsed flag -- makes ParseAuthorityIfNecessary idempotent (avoids false-positive on repeated calls after Authority is decomposed into Instance+TenantId)

Merge point coverage

The InstanceOrTenantIdExplicitlyConfigured latch is set at 4 user-config merge points:

1. UpdateMergedOptionsFromMicrosoftIdentityOptions -- Instance
2. UpdateMergedOptionsFromMicrosoftIdentityOptions -- TenantId
3. UpdateMergedOptionsFromConfidentialClientApplicationOptions -- Instance
4. UpdateMergedOptionsFromConfidentialClientApplicationOptions -- TenantId

Three synthetic merge points intentionally do NOT set the latch:

1. ParseAuthorityIfNecessary (decomposes Authority into Instance+TenantId)
2. UpdateMergedOptionsFromMicrosoftIdentityApplicationOptions -- Instance (computed getter)
3. UpdateMergedOptionsFromMicrosoftIdentityApplicationOptions -- TenantId (computed getter)

Test changes

• Conflict pinning tests converted to Assert.Throws<InvalidOperationException>
• Added SyntheticAuthority_NoThrow test (computed getter scenario = no conflict)
• Conflict tests updated to set both latches (AuthorityExplicitlyConfigured + InstanceOrTenantIdExplicitlyConfigured)
• Fixed 4 existing tests that incidentally created conflicts (redirect URI, regions, metadata address, CCA token-binding)

E2E validation

Manually tested with a learning app across all config scenarios:

• Instance+TenantId only: app starts and works correctly
• Authority only: app starts and works correctly (no false positive)
• Authority + Instance + TenantId (conflict): throws InvalidOperationException at startup with clear message

Fixes #3869
Builds on #3855

Once this is merged, will improve the docs in #3617 and merge that one