Preventing such a design is the whole reason for this feature request.
The UV method should be independent of the vault unlock method, because the threat models for the two uses are different, so the PIN entropy requirements will be different.
On non-mobile devices especially, the PIN is just a second password (i.e., it may contain non-numeric characters and have arbitrary length), so a security-conscious user may want a master password that is a 5-word passphrase (65 bits of entropy) and a vault unlock “PIN” that is a 3-word passphrase (39 bits of entropy). This is a rational choice if the user deems the probability of a local attack to be smaller than the probability of a cloud server attack by a factor of approximately 10-8 or smaller (justifying the 26-bit reduction in entropy).
Conversely, since the passkeys are already relatively protected by being stored inside the Bitwarden vault, the entropy requirements are much lower. Once Bitwarden achieves CTAP2 compliance, an all-numeric PIN with as few as 4 digits would be permissible, and I suspect that most users would be happy with this level of added protection (13 bits of entropy). A CTAP2-compliant implementation would also need to block the passkey use once 8 incorrect PIN entry attempts have been made — thus, a security-conscious user can follow the guidelines I have posted here to select the necessary entropy for the User Verification PIN. As shown in that analysis, a 4-digit numerical PIN (13 bits of entropy) is a very reasonable level of protection for a UV PIN — yet this would be much too simple of a PIN for protecting a locked vault (in fact, a 4-digit numeric vault PIN can be cracked by brute force in a few seconds).
Clearly, the security requirements for the vault unlock PIN and the UV PIN are completely different, so it is essential for these to be two different PINs, independent of each other.