New User can create personal vault entries until verified with org (when this is disabled by policy)

I'm using the hosted/cloud version of Bitwarden, we're an Enterprise sub in the setup/trial phase.

The org has the policy set where personal vaults are disabled (this is intentional). When I invite a new user (with the "User" class, haven't tested "Manager" calss), this New User can create personal vault entries until they gain access to the Org. Considering that the Org sent the invite, this should be disabled the whole way (unless the invite is rejected maybe?).

Order of operations:
1. Owner/Admin account (me) send invite to E-Mail address (SSO, if that's relevant here).
2. "New User" receives E-Mail, goes to bitwarden website, creates new account. Master Password policy complexity IS enforced here (success!).
3. "New User" is logged into their Bitwarden account, can now make personal vault credentials immediately. But cannot yet access Org content. (let's say they out of curiosity make a personal vault entry, for testing or whatever)
4. "New User" notices that they need to verify their E-Mail with the top right box in the web page saying so. "New User" clicks on the button to send validate E-Mail.
5. "New User" is sent to the bitwarden site to login (or equivalent) and now they can see the Org, and the Org content. "New User" can _still_ see the personal vault entry they made at step # 3. They cannot make new personal vault entries, but they can interact with/delete the personal vault entry made at step # 3. "New User" is likely now confused.

I'm hoping we can find an improvement to this workflow. The intent here is to reduce user error, confusion, and increase the consistency of the user experience. Additionally, why not just force the user to "Verify E-Mail" before they can even do anything at all? (Or make this a policy option?). I see there being a non-trivial amount of users that completely miss they need to verify their E-Mail, and then just start using the tool.

Frankly, this edge-case in the UX/workflow is something the end-users shouldn't have to worry about. Considering the Master Password complexity is enforced, it's surprising that the "no personal vault" policy isn't enforced to the same degree.

Any chance we can get this added to a kanban board somewhere/roadmap/milestone or whatnot? I don't expect this done "tomorrow" or even "ASAP". But I think improving/fixing this is worthwhile. And I really do think this qualifies for "bug", not "feature request" as this, in a sense, breaks the "no personal vault" policy enforcement capability.

Thoughts?

Reproduce the five-step flow described in the issue with personal vaults disabled by organization policy, including account creation before email verification and subsequent organization access. Compare the allowed actions and existing entry visibility at each step; done means the policy behavior is consistent throughout the invitation and verification flow, with the intended handling of any pre-policy entry made before access.

Written by the indexing model from the issue text.