Add WebAuthn Signal API support for passkeys

[rolandVi]

API proposal in #68165.
When someone deletes a passkey or changes their email, the browser's passkey provider now hears about it, so removed passkeys stop being offered at sign-in and the name shown next to a passkey stays right. Today the provider keeps its own copy and never finds out.

Usage

if (SignInManager.SupportsPasskeySignalOptions)
{
    var json = await SignInManager.MakePasskeySignalOptionsAsync(user, userEntity);
}

const { rpId, userId, allAcceptedCredentialIds, name, displayName } = JSON.parse(json);
await PublicKeyCredential.signalAllAcceptedCredentials?.({ rpId, userId, allAcceptedCredentialIds });
await PublicKeyCredential.signalCurrentUserDetails?.({ rpId, userId, name, displayName });

What changed

The payload is built by IPasskeyHandler<TUser>, so it resolves the RP ID the same way creation and assertion already do and a custom handler stays consistent with the passkeys it issued. SignInManager just delegates, like the other passkey methods. The interface shipped in .NET 10, so the new member is a default interface method that throws, paired with SupportsSignalOptions for callers to check first.

This has to live in the framework because an app can't easily assemble the payload: the user handle isn't the user ID, it's the UTF-8 bytes base64url encoded through the internal BufferSource. Get it wrong and the call silently does nothing.

The Blazor template renders a new <PasskeySignals> component on the manage passkeys page and after an email change. It's a custom element rather than JS interop because those pages are static SSR.

Not included

signalUnknownCredential is not here. It deletes permanently instead of hiding, and sign-in can't yet tell "unknown credential" apart from any other failure, so it needs an API addition first. Tracked in #68128.

Testing

Covered end to end with the CDP virtual authenticator: the signalled credential list has to match what the authenticator actually holds, and empty out after a delete.

Resolves #67299

[dotnet-policy-service]

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

[halter73]

Can you open an API proposal following the API review process? #67299 doesn't have a proposed API in it.

Things I'd want the proposal to settle: whether this belongs on IPasskeyHandler<TUser> rather than SignInManager, whether the returned JSON should be a superset of both signal payloads or something directly passable to each JS call, and whether MakePasskeySignalOptionsAsync is the right name once signalUnknownCredential (#68128) shows up, since that one takes a different payload and gets called before sign-in.

[rolandVi]

Opened #68165. It covers the mentioned talking points. I will align the design with @rokonec, as he will champion it through API review.