Here is my best evidence that Bitwarden is in fact bound by published specifications when requiring User Verification to be synchronous with the passkey authentication ceremony (ruling out the possibility of representing to Relying Parties that a prior, asynchronous vault unlock event “counts” as User Verification).
From the publication Web Authentication: An API for accessing Public Key Credentials. Level 2. W3C Recommendation, 8 April 2021, under §4 Terminology:
Authentication Ceremony
The ceremony where a user, and the user’s client (containing at least one authenticator) work in concert to cryptographically prove to a Relying Party that the user controls the credential private key of a previously-registered public key credential (see Registration). Note that this includes a test of user presence or user verification.
[emphasis added to the last sentence]
This makes it clear that User Verification is done during each authentication ceremony. Section §7.2 (Verifying an Authentication Assertion) defines the requirements of the authentication ceremony. There, we find:
In order to perform an authentication ceremony, the Relying Party MUST proceed as follows:
…
17. If user verification is required for this assertion, verify that the User Verified bit of theflagsin authData is set.
The UV bit is set by the authenticator (e.g., Bitwarden) during the ceremony.
As an additional data point, it is clear that Bitwarden does consider the new behavior (synchronous UV during each authentication ceremony) to be be required by the specification, as evidenced by a recent Reddit comment by @kspearrin:
They [1Password] ignore the specification’s requirement to prompt for user verification, which we were previously doing as well for the sake of UX.
See also comments by timcapalli in this thread on the KeePassXC GitHub repo, as well as the assessment by passkeys.dev that was previously linked by @Nail1684.