Probably should have added more information.

Client:

[zack@laptop ~]$ ssh -V
OpenSSH_9.9p1, OpenSSL 3.4.0 22 Oct 2024
[zack@laptop ~]$ uname -a
Linux laptop 6.12.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 22 Nov 2024 16:04:27 +0000 x86_64 GNU/Linux
[zack@laptop ~]$ cat .ssh/config
Host *
	ChallengeResponseAuthentication no
	CheckHostIP yes
	Ciphers chacha20-poly1305@openssh.com
	Compression yes
	ConnectTimeout 30
	GlobalKnownHostsFile /etc/ssh/ssh_known_hosts
	HostKeyAlgorithms ssh-ed25519
	IdentitiesOnly yes
	IdentityFile ~/.ssh/29404731
	KexAlgorithms sntrup761x25519-sha512@openssh.com
	PasswordAuthentication no
	PreferredAuthentications publickey
	PubkeyAcceptedAlgorithms sk-ssh-ed25519@openssh.com
	StrictHostKeyChecking yes
	UpdateHostKeys no
	User zack
	UserKnownHostsFile ~/.ssh/known_hosts

I don't use ssh-agent, and ~/.ssh/29404731 is not protected by passphrase.

Server:

router$ uname -a
OpenBSD router.philomathiclife.com 7.6 GENERIC.MP#338 amd64
router$ sshd -V
OpenSSH_9.9, LibreSSL 4.0.0
router$ cat /etc/ssh/sshd_config
AllowUsers staging zack
AuthenticationMethods publickey
Ciphers chacha20-poly1305@openssh.com
HostKey /etc/ssh/ssh_host_ed25519_key
HostKeyAlgorithms ssh-ed25519
KexAlgorithms sntrup761x25519-sha512@openssh.com
ListenAddress fdb5:d87:ae42:1::1
ListenAddress 192.168.1.1
MaxAuthTries 2
MaxSessions 1
PasswordAuthentication no
PermitRootLogin no
PubkeyAcceptedAlgorithms sk-ssh-ed25519@openssh.com
PubkeyAuthOptions touch-required verify-required
Subsystem sftp internal-sftp

Match User staging
	ChrootDirectory ~/
	ForceCommand internal-sftp
	PubkeyAcceptedAlgorithms ssh-ed25519

Additionally, I've been using client-side/"resident" ed25519-sk keys for
years since it was first enabled. Before this Bio key, I was using a
YubiKey 5C running firmware 5.4.3. Before that, it was a YubiKey 5Ci
running an older firmware. They've all worked fine with PINs-technically,
I use a passphrase since it's not just "numbers" that work. This is
my first biometric and PIN-based authenticator, so I can't report what
the behavior used to be like.

To be clear, I'm not complaining that I'm unable to use a PIN; nor am I
claiming that there don't exist certain server and client configurations
that allow PINs for the YubiKey Bio; however, using _my_ client and
server config and specific Bio key, fingerprint authentication works
(and only works). If my config is too niche to not adjust the man page,
then I understand. I honestly wasn't confident it would work especially
after reading ssh-keygen(1); however, to my delight, it does. I can see
people not even bothering because of it, hence my suggestion to "fix" it.

If it helps, I am enrolled in Google's Advanced Protection program; and
I have this FIDO key registered as a passkey. When I use Firefox to log
into Google and I fail biometric authentication 3 straight times, it
prompts me to enter the PIN which both unlocks the FIDO key-allowing me
to not have to manually unlock it (e.g., via ykman)-and logs me in.
ssh(1) does not do that. Once I fail, I have to run the command again.
I think _if_ the expectation is to fall back to PIN like many WebAuthn
services do, then ssh(1) must not exit the program with an error like
below:

sign_and_send_pubkey: signing failed for ED25519-SK
"/home/zack/.ssh/29404731": invalid format
zack@router: Permission denied (publickey).

Instead it must attempt at least 4 times; with the 4th time requesting a
PIN, which upon success will unlock the FIDO key. Presumably ssh(1) will
be notified of the success which it can then interpret as a successful
authentication as well.

YubiKey Bio is a Client to Authenticator Protocol (CTAP) 2.1
authenticator unlike my previous ones which were CTAP 2.0. I've never
dealt with that protocol before, but I have dealt with WebAuthn since
I'm a contributor to the spec and maintain a WebAuthn RP library. Anyway
since I've never written code that actually communicates with the
authenticator, I am unable to say how difficult it would be to achieve
what user agents/client platforms (e.g., Firefox) do-again, assuming
that's even a desire for ssh(1). I know I don't have to provide the
spec, but here it is just in case:

https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html