Document IPasskeyHandler and attestation state validation

[rolandVi]

Resolves #37437. Tracked by dotnet/aspnetcore#66750.

IPasskeyHandler<TUser> is public API with no docs. An app that calls it directly takes over storing the attestation state between the two registration requests, and that state is what decides which account the new passkey ends up on. The passkeys article only covers the SignInManager path today, so anyone stepping off it has nothing to go on. This adds a section on when to reach for the handler and what the app becomes responsible for once it does.

What changed

One new H2, Customize the passkey handler, in aspnetcore/security/authentication/passkeys/index.md. Five subsections: when to implement the interface, what the attestation state is, the three things an app has to get right (integrity, ownership, single use), a worked registration example, and how to register a custom handler.

It sits after Custom origin validation and before Registration flow, so the customization sections run least to most invasive. The Step 2 paragraph in the registration flow now points at it, since that's where the state is first mentioned.

The example keeps the state in a data-protected cookie rather than server-side session state. It needs no extra infrastructure and it mirrors what SignInManager already does.

The DI subsection flags that AddSignInManager registers the default handler with AddScoped, not TryAddScoped (IdentityBuilderExtensions.cs line 44), so a custom handler registered before the Identity calls is silently replaced. Worth a reviewer's eye, it's easy to get wrong and you can't tell from the API.

---

Internal previews

File	Preview link
aspnetcore/security/authentication/passkeys/index.md	aspnetcore/security/authentication/passkeys/index

[guardrex]

Thanks @rolandVi! ... I'm heading OOF for the weekend shortly, so I'll look at this next week. Have a great weekend! 🍻