What does this PR do?

Fixes three bugs in the signup watchlist review feature introduced in #27912, and adds auto-unlock behavior when SIGNUP-source watchlist entries are removed.

Bug Fixes

1. GlobalWatchlistRepository.deleteEntry missing await — Prisma queries are lazy; without await, the delete was silently never executed. This caused watchlist entries to persist even after an admin unlocked a user.

2. Email verification race condition — sendEmailVerification was called (fire-and-forget) BEFORE the watchlist check added the email to the blocklist. By the time sendEmailVerification ran its internal watchlist check, the email was already blocked, so no verification token was ever created. Fixed by moving sendEmailVerification to AFTER the watchlist early-return path, so it only runs for non-watchlisted signups.

3. No verification email on unlock — After an admin unlocks a user and removes them from the watchlist, the user had no way to verify their email. Now sendEmailVerification is called after unlock in lockUserAccount.handler.ts.

Additionally, sendEmailVerification is now scoped to non-invite signups (!checkoutSessionId && !token) to prevent redundant verification emails for team invite users who already have emailVerified set.

New: Auto-unlock on SIGNUP watchlist entry removal

When a watchlist entry with source: SIGNUP and type: EMAIL is deleted (single or bulk) via AdminWatchlistOperationsService, the associated user is automatically:

• Unlocked (via new UserRepository.unlockByEmail)
• Sent a fresh verification email

This works for both deleteWatchlistEntry (single) and bulkDeleteWatchlistEntries (bulk). Errors in the unlock/email flow are caught and logged — they do not block the deletion itself.

• Fixes issues reported in feat: add signup watchlist review mode #27912 review

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I confirm automated tests are in place that prove my fix is effective or that my feature works.
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. N/A

How should this be tested?

1. Enable the signup-watchlist-review feature flag in the database
2. Sign up a new user (non-invite flow, non-premium username)
3. Verify the watchlist entry has source: 'SIGNUP' (not 'MANUAL')
4. Verify no verification email is sent at signup (email is blocked by watchlist)
5. As admin, unlock the user via the admin panel
6. Verify the watchlist entry is deleted from the database
7. Verify the user receives a fresh verification email after unlock
8. Verify the verification link works
9. New: As admin, remove a SIGNUP-source watchlist entry directly from the watchlist management UI
10. Verify the associated user is automatically unlocked and receives a verification email
11. Verify removing a MANUAL-source entry does not trigger auto-unlock

Human Review Checklist

⚠️ Important items for reviewer attention:

• sendEmailVerification in unlock handler is awaited (lockUserAccount.handler.ts:45): Unlike the fire-and-forget pattern in the signup handler, the unlock handler awaits the call. If the email service fails, the unlock response will also fail. Confirm this is acceptable or if it should be fire-and-forget.

• deleteEntry await fix (GlobalWatchlistRepository.ts:166): Confirm the missing await was indeed the root cause of watchlist entries not being deleted on unlock.

• Order of operations in signup handler (calcomSignupHandler.ts:320-326): The watchlist check + early return now happens BEFORE sendEmailVerification. For the watchlist review path, the handler returns at line 317, so sendEmailVerification at line 320 is never reached — which is the correct behavior.

• !token guard on sendEmailVerification (calcomSignupHandler.ts:320): Team invite signups (token flow) already set emailVerified directly, so they skip verification. Confirm this guard is correct.

• Auto-unlock error handling (AdminWatchlistOperationsService.ts:215-227): The unlockSignupUser method catches errors and logs them but does not throw. This means if unlock fails, the watchlist deletion still succeeds. Confirm this is the desired behavior (deletion should not be blocked by unlock failures).

• Non-atomic unlock (UserRepository.ts:1440-1459): unlockByEmail uses findFirst + update (two queries). There's a theoretical race condition if the user gets locked between find and update. Low risk but worth noting.

• findEntriesByIds interface expansion (WatchlistRepository.ts:237-244): Now returns source, type, value fields. Verify no other callers depend on the previous narrower return type.

Link to Devin run: https://app.devin.ai/sessions/89436f0e54694e308731b95c32036f1d
Requested by: @alishaz-polymath