Login email code is silently dropped for suppressed addresses, locking users out #128361

Problem

Login silently fails for any account whose email address is on the hard-bounce suppression list. The login screen says "we've emailed a 6-digit verification code", but the code is never sent, so the user retries and resends with no way of knowing why nothing arrives.

How we hit it

• Our Google Workspace (openfundraise.org) was briefly suspended for billing on Sep 5–7, 2026, so incoming mail bounced for about two days.
• PostHog's daily pipeline-alert emails to support@openfundraise.org bounced during that window, and the address appears to have been suppressed permanently.
• The mailbox has worked normally since Sep 7, but it has not received a single PostHog email since Sep 5: no alerts, digests, billing notices, or login codes. Login codes to the same address arrived fine on Aug 24, 28 and 31.
• On Nov 3, email + password login stopped at "Check your inbox" every time. Resend did nothing visible. We only got in because the account could also sign in with Google.

Why it happens now

• fix(auth): add a flag to always send the login email code #126354 (merged Oct 30) always requires the login email code, even when the address is suppressed. Before that, suppressed addresses skipped the code step.
• fix(messaging): send transactional workflow email unless the address hard-bounced #124638 sends transactional email unless the address has hard-bounced, so the code is refused.
• fix(email): tell users when their address can't receive auth email #126352, which would have shown "We can't deliver email to this address", was closed without merging.
• Hard bounces do not expire (the expiry work in feat(workflows): add known-invalid email address table #128045 / feat(workflows): keep removed addresses off the known-invalid list #128046 was closed), so a short outage becomes a permanent block.

An account with only password + email code and a suppressed address is now locked out with no explanation.

Suggested fix

1. When the code email is refused, say so on the verification screen and link to support.
2. Expire hard bounces after a reasonable period, or clear them after a later successful delivery, so a temporary mailbox outage does not block an address forever.
3. Let a signed-in user see and clear their own address's suppression (for example, after signing in with SSO), instead of requiring support.

Request

Please also remove support@openfundraise.org (US Cloud, org OpenFundraise) from the transactional email suppression list.