Test for browser webauthn support (expression policy?)

**Is your feature request related to a problem? Please describe.**
A WebAuthn Validator or Configuration stage will immediately jump the user into a passkey prompt, and it can't be escaped as there is no other buttons on the stage except the "retry" when it is canceled. The user can at least hit the back button in their browser, and hopefully the previous stage gives them different options.

This however is a big problem for a passwordless-first strategy, because **there is no way to handle the case when a user's device does not support WebAuthn**. I tested my site on Midori, for example, and the webauthn stage _fails instantly_ the same way, with "Authentication failed. Please try again." and a button to try again. That's pretty bad UX as is, because trying again cannot possibly work when the failure was due to no browser support.

But the bigger issue is that you're then stuck at that stage -- there's no way to account for this on Authentik's end, or at least I couldn't find any info online or in the docs on how to test for webauthn support.

**Describe the solution you'd like**
Ideally this would be done in an expression policy, so I can avoid sending the user to anything passkey related when the device does not support it. I understand this is difficult because the python runs server-side, whereas the javascript to test for webauthn support would be client side. But the client side could store the webauthn support boolean in `pending_user` or something to make it available to a policy.

Even if it's not possible to use in a policy, there should be a client-side check and some sort of recourse when it's not supported.

**Describe alternatives you've considered**
A policy can test if a user has configured a passkey, which I currently do. If the user has no passkey configured, however, _that doesn't mean their device doesn't support it_ -- they just haven't added one yet.

Crucially, if the user does have a passkey configured, _that doesn't mean their current device/browser supports webauthn_ - so this can't really be used to determine support either.

Start by tracing the WebAuthn Validator and Configuration stages, then review how expression policies access pending_user. Check where client-side WebAuthn support could be detected and how that result could reach the server; done means unsupported browsers avoid the passkey stage or receive a usable alternative.

Written by the indexing model from the issue text.