Support conditional passkey creation

[rolandVi]

API proposal tracked by #68192.

A Blazor Identity app can now create a passkey for someone silently, right after they sign in with a password, so they get moved off passwords without seeing a prompt or having to find a button. Today a passkey only appears if the user goes looking for the "add a passkey" page, which almost nobody does.

Example usage

if (SignInManager.SupportsPasskeyConditionalCreation)
{
    creationOptionsJson = await SignInManager.MakePasskeyCreationOptionsAsync(
        userEntity,
        isConditionallyMediated: true);
}

Why the server needs telling

This needs new public API because the server cannot work it out for itself. Mediation is not in clientDataJSON, so it cannot be inferred, and taking it from the client at attestation time would let anyone switch off the user-presence check. It is supplied when the options are made and rides along in the data-protected attestation state.

Design notes

Two checks get relaxed. The spec's registration steps skip the user-presence check when mediation is conditional, and the client is required to report both presence and verification as false. Separately, UserVerificationRequirement is downgraded from "required" to "preferred" in the generated options, because the browser refuses the ceremony outright if a conditional create asks for verification, so without that downgrade nothing reaches the server to verify.

I used a bool overload rather than an options object because an options object is source-breaking here: it makes existing new() { ... } call sites ambiguous. Details in the proposal.

SupportsConditionalCreation is there so an app with a custom IPasskeyHandler can ask before calling instead of getting an exception on every sign-in.

Template changes

The Blazor template sends the user through a short /Account/PasskeyUpgrade page after a completed sign-in, which does the creation and then continues to wherever they were headed. It is a separate page rather than something inline on the login page because navigating away cancels the login page's in-flight conditional get(), which the browser wants aborted before a conditional create starts.

The options are created in the sign-in handler itself, on the password, two-factor and recovery-code paths, and carried to the upgrade page in protected TempData. The upgrade page has no code that can issue options: reached without them, it redirects and does nothing. That keeps the decision to relax the registration checks with the code that just checked a credential, rather than with any request carrying a session cookie. It gives up after 5 seconds, and any failure is logged and swallowed, since the user never asked for this and should not see it fail.

Adding a passkey with only a session cookie is wider than this page. #66865 tracks the same weakness on the existing passkey management page and is not addressed here.

Testing

Unit tests cover the verification downgrade, the flag round-tripping through the attestation state, a conditional create succeeding with both flags false, an ordinary create still rejecting a missing user-presence flag, and the NotSupportedException from the default interface method.

The template E2E test stubs getClientCapabilities and intercepts navigator.credentials.create, recording the mediation it was called with. It checks a conditional create is attempted after a password sign-in, after two-factor and after a recovery code, that none is attempted at the two-factor prompt itself, and that navigating straight to /Account/PasskeyUpgrade with a session cookie attempts nothing. The interception means the E2E does not exercise attestation for a conditional create; the server side is covered by the unit tests

Resolves #67298.

[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.