Describe the bug

This is with stage-1 systemd initrd.

I cannot use my FIDO2 token to unlock my LUKS volume at boot, when these conditions are met:

• the token is plugged in, and remains plugged in during boot
• I have used --fido2-with-client-pin=false when I initialized the token/keyslot in LUKS

After 30 seconds, it falls back to password.

That is, it works if I do either:

• unplug/replug during the 30 second window, it starts flashing, I tap, it unlocks and boots
• don't add the above flag disabling user verification (aka, with client pin), at boot, I'm immediately prompted for my PIN, I enter, it flashes, I tap, it unlocks and boots.

Steps To Reproduce

1. Enroll a FIDO2 token without client-pin (systemd-cryptenroll --fido2-device auto /dev/nvme0n1p7)
2. Try to boot and unlock with that FIDO2 token

NOTE: similar to #265366, if I sudo -s, set LD_LIBRARY_PATH to include ${pkgs.systemd}/lib/cryptsetup, I'm able to use cryptsetup to unlock with my token with just a tap (no PIN, as expected).

I'm not sure, this could be an upstream issue. It's interesting that it works so quickly when using PIN verification, especially since it works with the PIN enabled, and cryptsetup is able to open it either way.

cc: @ElvishJerricco