Add Name parameter to UserPasskeyInfo constructor

[BloodShop]

Summary

UserPasskeyInfo exposes a Name property but the constructor doesn't accept it — it's the only property left out. Callers have to fall back to an object initializer:

var passkey = new UserPasskeyInfo(credentialId, publicKey, ...)
{
    Name = "My Security Key"  // why can't this go in the constructor?
};

This adds a constructor overload so Name can be set inline with everything else.

What changed

UserPasskeyInfo gets a second constructor with an additional trailing string? name parameter. The original constructor delegates to it with name: null, so nothing breaks — existing call sites compile and behave exactly as before.

UserPasskeyInfo.cs

• New constructor overload: ..., byte[] clientDataJson, string? name)
• Original constructor chains into it via : this(..., name: null)

PublicAPI.Unshipped.txt

• New API entry for the overloaded constructor

UserPasskeyInfoTest.cs (new file)

• Verifies the new constructor sets all properties including Name
• Verifies passing null leaves Name unset
• Verifies the original constructor still works and leaves Name null

Usage

// Before (still works)
var passkey = new UserPasskeyInfo(credentialId, publicKey, createdAt,
    signCount, transports, isUserVerified, isBackupEligible, isBackedUp,
    attestationObject, clientDataJson)
{
    Name = "My Security Key"
};

// After (also works now)
var passkey = new UserPasskeyInfo(credentialId, publicKey, createdAt,
    signCount, transports, isUserVerified, isBackupEligible, isBackedUp,
    attestationObject, clientDataJson, name: "My Security Key");

Breaking changes

None. The existing constructor signature is untouched and remains in PublicAPI.Shipped.txt. The new overload is additive only.

Fixes #65774

[dotnet-policy-service]

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

[BloodShop]

@dotnet-policy-service agree

[BloodShop]

CI Failure Analysis - Flaky Test Issue

The current CI failure is unrelated to this PR's code changes:

Failed Test: Microsoft.AspNetCore.SignalR.Client.Tests.TestServerTests.WebSocketsWorks
Error: ObjectDisposedException: Cannot access a disposed object. Object name: 'IServiceProvider'

Evidence this is a known flaky test:

• ✅ PR [blazor][wasm] JSExport for events #65897 had the identical failure and was merged today (2026-03-23)
• ✅ This PR only modifies UserPasskeyInfo.cs (Identity/Passkey code) - zero relation to SignalR
• ✅ The error is a race condition in SignalR test teardown, not related to passkey functionality

Files changed in this PR:

• src/Identity/Extensions.Core/src/UserPasskeyInfo.cs
• src/Identity/Extensions.Core/src/PublicAPI.Unshipped.txt
• src/Identity/test/Identity.Test/UserPasskeyInfoTest.cs

Request: Please consider re-running CI or merging despite the flaky test, as this follows the established precedent of PR #65897 which had identical infrastructure failures.

The code changes are solid and well-tested - this is purely an infrastructure timing issue.

[BloodShop]

CI Status Update (March 26, 2026)

All CI failures on this PR are infrastructure flaky tests unrelated to our changes. Here is the evidence:

✅ What Passes (all green)

• Build: Linux x64, Windows x64/x86/arm64, macOS x64/arm64
• Code check, Source-Build (Managed)
• Test: Ubuntu x64, Windows Server x64, Windows local dev, macOS
• Quarantined test runs (all pass)

❌ What Fails (random Helix tests)

Latest run (build 1353428): Interop.FunctionalTests (Http2WebSocket PingTimeout), Http.Abstractions.Tests (FailFast crash), Identity.FunctionalTests (Helix infra), OutputCaching.Tests (Helix infra), DataProtection.Tests (DeleteKeys flaky), Mvc.Razor.RuntimeCompilation.Test (Python _cffi_backend module error)

🔍 Key Evidence

1. Main branch is also failing — 8 of the last 10 rolling CI builds on main have failed with the same pattern
2. Different random tests fail each run — these are not deterministic failures
3. Other PRs merged despite failures — e.g. [test-quarantine] Unquarantine Http3RequestTests.POST_ClientCancellationBidirectional_RequestAbortRaised (issue #38008) #65972 and [test-quarantine] Unquarantine QuicStreamContextTests.BidirectionalStream_MultipleStreamsOnConnection_ReusedFromPool (issue #59978) #65971 were merged with identical failures
4. Branch is up to date — 0 commits behind main, no rebase needed
5. 6 CI runs attempted — 1 passed (March 18), 5 failed with different random tests each time

🙏 Request

Could a maintainer please use /ba-g to override the Build Analysis check, or merge this PR? The code changes (adding Name parameter to UserPasskeyInfo constructor) are isolated to Identity code and have zero relation to the failing tests.

[dotnet-policy-service]

Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime.
To make sure no conflicting changes have occurred, please rerun validation before merging. You can do this by leaving an /azp run comment here (requires commit rights), or by simply closing and reopening.