[PM-40152] feat: Require verified email to accept organization invite link

[r-tome]

🎟️ Tracking

Resolves PM-40152

📔 Objective

The invite-link accept flow (AcceptOrganizationInviteLinkCommand) gated organization membership on the accepting user's email domain being in the link's AllowedDomains, but never asserted the email was verified. Unlike the email-invite flow — where the token delivered to the mailbox proves ownership — the invite link carries no per-email token, so the domain allowlist was the only binding between the user and an allowed domain. An account holding an unverified email at an allowed domain could therefore join the organization.

This PR adds a !user.EmailVerified guard in the read-only validation phase of the accept command, before any OrganizationUser is created or seat is consumed. Unverified users receive a new EmailNotVerified error (HTTP 400). New unit tests cover the rejection and confirm no membership/seat side effects occur.

SSO JIT-provisioned users are not affected: the JIT flow creates an org user in an invited state and accepts them via IAcceptOrgUserCommand (through the MP, TDE, or Key Connector paths), never through AcceptOrganizationInviteLinkCommand.

Surfaced by the AppSec review of the invite-link tech breakdown.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

This PR adds a !user.EmailVerified guard to AcceptOrganizationInviteLinkCommand, closing a gap where an account holding an unverified email at an allowed domain could join an organization. The guard sits in the read-only validation phase, before any OrganizationUser is created or seat consumed, and returns a new EmailNotVerified (HTTP 400) error that follows the existing error-record pattern. A new unit test verifies the rejection and confirms no membership or seat side effects occur, and SetupHappyPath now sets EmailVerified = true so existing tests remain valid under the new guard.

Code Review Details

No findings. The guard is correctly ordered ahead of state mutation, User.EmailVerified is a non-nullable bool so the check is safe, and the SSO JIT-provisioning concern was investigated and ruled out (JIT users accept via IAcceptOrgUserCommand, not this command).

[r-tome]

@JaredSnider-Bitwarden tagging you here because this PR requires EmailVerified to be true before a user can accept an invite link. SSO-provisioned accounts don't seem to get EmailVerified = true, so I want to check whether a user coming through the SSO route could get blocked at accept. I'm keeping this as a draft until we align.

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 61.45%. Comparing base (19c6afb) to head (2e4fd20).
⚠️ Report is 18 commits behind head on main.

Files with missing lines	Patch %	Lines
...Console/OrganizationFeatures/InviteLinks/Errors.cs	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7949      +/-   ##
==========================================
+ Coverage   61.43%   61.45%   +0.01%     
==========================================
  Files        2245     2245              
  Lines       98830    98859      +29     
  Branches     8941     8946       +5     
==========================================
+ Hits        60715    60749      +34     
+ Misses      35965    35960       -5     
  Partials     2150     2150              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[r-tome]

@JaredSnider-Bitwarden tagging you here because this PR requires EmailVerified to be true before a user can accept an invite link. SSO-provisioned accounts don't seem to get EmailVerified = true, so I want to check whether a user coming through the SSO route could get blocked at accept. I'm keeping this as a draft until we align.

Investigated by Auth. SSO JIT-provisioned users are not affected. The JIT flow creates the org user in an invited state and accepts them via IAcceptOrgUserCommand (through the MP, TDE, and Key Connector paths), not through AcceptOrganizationInviteLinkCommand. Marking ready for review.