[test-quarantine] Fix the UserManagerWillUseTokenProviderInstanceOverDefaults test failure

[karmegams02]

Summary

Preserve user-supplied ProviderInstance in IdentityBuilder.AddTokenProvider instead of nulling it out.

Description

IdentityBuilder.AddTokenProvider previously set descriptor.ProviderInstance = null whenever a token provider with the same name had already been registered (e.g. by AddDefaultTokenProviders). The intent of that assignment was to keep multiple UserTypes working side by side, but the side effect was that any ProviderInstance the developer had explicitly attached to the descriptor was discarded. A custom token provider instance registered via o.Tokens.ProviderMap[name] = new TokenProviderDescriptor(...) { ProviderInstance = ... } was therefore ignored, and the framework fell back to the default provider type registered by AddDefaultTokenProviders.

This change preserves the multi-UserType support (provided by the type stack in TokenProviderDescriptor.AddProviderType) while allowing an explicit ProviderInstance to take precedence over the default provider type.

Changes

• src/Identity/Extensions.Core/src/IdentityBuilder.cs: drop descriptor.ProviderInstance = null; inside the Configure<IdentityOptions> block; update the explanatory comment to describe the new contract (type stack is preserved, an explicit ProviderInstance wins over the default type).
• src/Identity/test/Identity.Test/UserManagerTest.cs: un-skip UserManagerWillUseTokenProviderInstanceOverDefaults. With the regression fixed, the test now passes and continues to assert that a user-supplied ProviderInstance is preferred over the default token provider type.

Why this is safe

• The multi-UserType behavior is preserved by the provider type stack in TokenProviderDescriptor.AddProviderType, which is unchanged.
• Callers that do not set ProviderInstance are unaffected: they continue to get the default type from AddDefaultTokenProviders followed by any additional AddTokenProvider<…>(name) calls.
• Only callers that explicitly set ProviderInstance on a TokenProviderDescriptor see a behavior change, and that change is the documented and tested behavior.

Fixes #57361

[dotnet-policy-service]

Thanks for your PR, @karmegams02. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

Pull request overview

Fixes an Identity token-provider resolution regression where IdentityBuilder.AddTokenProvider discarded a developer-supplied TokenProviderDescriptor.ProviderInstance when a provider name was already present (e.g., after AddDefaultTokenProviders). The change preserves the existing multi-UserType behavior (provider type stacking) while ensuring an explicitly configured provider instance takes precedence.

Changes:

• Stop clearing TokenProviderDescriptor.ProviderInstance when AddTokenProvider encounters an existing provider-name entry; continue stacking provider types for multi-UserType support.
• Re-enable UserManagerWillUseTokenProviderInstanceOverDefaults now that the framework correctly prefers the configured instance over default provider types.

Show a summary per file

File	Description
src/Identity/Extensions.Core/src/IdentityBuilder.cs	Preserves ProviderInstance when stacking provider types for an existing provider name.
src/Identity/test/Identity.Test/UserManagerTest.cs	Unskips a test that verifies ProviderInstance wins over default token provider registrations.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 0

[kotlarmilos]

LGTM! @ilonatommy this is identity area, right?