Add comprehensive email validation for blocked users

Hi there 👋

This MR introduces the BlockedEmail model, a reusable EmailValidator, and client-side handling to enforce a blocklist of emails during account creation. The core server-side blocking works and locale/autoload wiring is consistent, but the review found several blocking concerns that must be addressed before merge.

Most important: BlockedEmail.should_block? is a predicate that also mutates the database (increments match_count, touches last_match_at, saves). It is invoked from inside validate_each, so every email change performs a DB write — and the unauthenticated users#create action runs the validator twice per request (once via user.valid?, once via user.save), guarded only by a static honeypot. This both inflates stats with failed attempts and opens a new resource-exhaustion/DoS vector on POST /users. The match_count += 1; save increment is also a non-atomic read-modify-write that can lose increments under concurrency; record.save additionally swallows failures. The validator should be made side-effect-free (defer tracking to an explicit non-validation path) and use an atomic single-statement update.

Contract / behavior gaps: the new blocklist gate applies to create_for_email flows (invite redemption, DiscourseHub account creation) with no rescue of RecordInvalid — confirm this is intended; and because the gate runs only when the email changes, it never applies retroactively to existing users. On the client, the rejected-email reason is lost (a generic "is not valid" is shown instead of the server's "is not allowed"), the rejectedEmails mechanism pins on any email error and never clears, and its case/normalization comparison can fail to engage. The server's error response shape is also inconsistent across failure branches.

No review task reported errors, so findings reflect the reviewed scope. Several REQUEST_CHANGES were recommended; I concur and request changes before merge.

These might need a close look

• 🔴 lib/validators/email_validator.rb (L13)
  Side-effectful DB write inside the validator. BlockedEmail.should_block?(value) mutates the database (increments match_count, sets last_match_at, saves) as a side effect of every email validation — including for action_type == :do_nothing records and when the surrounding save will later fail (e.g. invalid username), so stats are inflated by failed attempts. Compounding this, users#create runs the validator twice per request (user.valid? at users_controller.rb:168 then user.save at :172), so a single POST for a blocked address performs two DB writes, and the action is unauthenticated/CSRF-free and only rate-limited by a static honeypot — enabling a resource-exhaustion / match_count-inflation flood vector. Split should_block? into a pure predicate plus an explicit track! step not invoked during validation, and avoid evaluating it twice per create (e.g. run the save only or gate to a single call). Also confirm the write-per-check cost for :do_nothing entries (blocked_email.rb:12) is intended.
• 🔴 app/models/blocked_email.rb (L14)
  Non-atomic read-modify-write on match_count. record.match_count += 1 followed by record.save is a classic race: should_block? runs in a concurrent hot path (simultaneous signups from the same spam address), so two requests can read the same value, both increment to the same number, and both save — silently losing increments and racing on last_match_at. Use an atomic single-statement update, e.g. BlockedEmail.where(id: record.id).update_all(['match_count = match_count + 1, last_match_at = ?', Time.zone.now]).
• 🔴 app/models/user.rb (L47)
  Blast radius: the new BlockedEmail gate now runs for every save! in create_for_email flows — invite redemption (InviteRedeemer#redeem) and DiscourseHub account creation — so a blocked email will now raise ActiveRecord::RecordInvalid where it previously succeeded. Confirm this is intended and that callers handle the validation failure gracefully (they do not appear to rescue RecordInvalid); if the blocklist should only gate self-registration, gate the email: true validation accordingly.

Worth checking

• 🟡 app/models/blocked_email.rb (L16)
  record.save runs the full validation suite on every stats bump and returns false on failure without signalling it; the method then returns based on action_type regardless of write success, so statistics can be dropped silently. Prefer update_column(:match_count, ...)/update_columns (skips validations/callbacks) or record.save!, and at minimum do not ignore the return value.
• 🟡 lib/validators/email_validator.rb (L21)
  The validator runs when the email is blank/empty (form posting an empty field), producing a spurious not_allowed error on top of the presence error and issuing a BlockedEmail.where(email: nil) query. Short-circuit on blank value (e.g. return if value.blank?) or only run the validator when email.present?.
• 🟡 spec/components/validators/email_validator_spec.rb (L9)
  The dedicated validator spec never exercises the whitelist/blacklist branches: both cases use bad@spamclub.com and differ only by a stubbed BlockedEmail.should_block?. Add positive/negative cases for whitelist and blacklist settings, case-insensitivity, and the interaction where the BlockedEmail check is skipped when a restriction error was already added.
• 🟡 app/models/user.rb (L47)
  The blocklist gate only runs when the email changes (if: :email_changed?), so an already-registered user whose email is later added to BlockedEmail is never re-screened. Given the MR's goal of comprehensive email blocking, confirm whether existing users should be re-screened (e.g. at login) or accept this limitation.
• 🟡 app/assets/javascripts/discourse/controllers/create_account_controller.js (L73)
  Rejected-email reason is lost: emailValidation returns the generic user.email.invalid regardless of why the server rejected the address, whereas the actual blocked reason is user.email.blocked = "is not allowed." (server.en.yml:734). The client and server therefore disagree on the message for the same condition. Store the authoritative reason from result.errors.email (an array) alongside the rejected email and render it rather than the hard-coded generic message; align the server and client copy.
• 🟡 app/assets/javascripts/discourse/controllers/create_account_controller.js (L274)
  rejectedEmails sticky-blocks on ANY email error (uniqueness, not_allowed, blocked) and never clears, so non-blocked conditions pin misleading "is not valid" and the user cannot resubmit for the page session. Also, emailValidation compares the raw case-preserved accountEmail against the possibly-normalized result.values.email; if they differ (e.g. Foo@Bar.COM vs foo@bar.com) the .contains(email) guard silently fails to engage, so resubmission of a blocked email is not prevented client-side. Confirm the normalization and make the comparison consistent/case-insensitive.

✅ Feature-level checklist

Partially covered

• ⚠️ Add comprehensive email validation for blocked users (enforce a BlockedEmail blocklist during email validation).
  Server-side blocking during email validation is implemented and works for new/self-registered users, but the requirement is not fully met: the blocklist only applies when the email changes (not retroactively to existing users), the client-side guard is unreliable due to case/normalization mismatch, and the validation path performs mutating DB writes (twice per create) with an unconfirmed blast radius on invite/hub-account flows. These gaps should be resolved to consider the feature comprehensive.