Merge pull request 'Validate signup email and password strength' (#155) from feature/150-signup-credential-validation into main

Reviewed-on: #155

docs/features/account-registration.md

@@ -77,6 +77,40 @@ confirmation token's SHA-256 hash is stored; the token expires after 48h
 | `accepted_at`      | DATETIME         | When accepted; NULL while pending / for group links     |
 | `expires_at`       | DATETIME         | Explicit expiry (end of the chosen day); set on every group link, NULL for personal invites (which expire 14 days after creation) |
 
+## Email and password validation
+
+Both are checked on the server on every signup path, and the browser is given a
+matching but *stricter* job so a bad password is caught before submitting.
+
+**Email** — `type="email"` and `required` in the markup, `is_email()` on the
+server, then `email_exists()` for "an account already exists for this email". A
+personal invite fixes the address and the server always uses the invite's own
+value, so a tampered field is ignored rather than validated.
+
+**Password** — `Auth\PasswordPolicy` is the authority. It deliberately does
+*not* try to reproduce a strength score in PHP; it rejects the categorically
+bad, which is what a server can check without shipping a dictionary:
+
+- shorter than `PasswordPolicy::MIN_LENGTH` (8 — NIST SP 800-63B's floor;
+  composition rules like "must contain a symbol" are deliberately **not** used,
+  as they push people towards predictable substitutions),
+- one of the well-known leaked passwords,
+- built from fewer than four distinct characters (`aaaaaaaa`, `abababab`),
+- containing the user's own display name, email, or the part before the `@`.
+
+The nuance happens in the browser. `register.js` scores the password with
+zxcvbn through WordPress's own `password-strength-meter` script and refuses to
+submit below `PasswordPolicy::MIN_SCORE` (2 of 4 — "medium"; enough to stop a
+guessable password without demanding a passphrase to book a piano lesson). The
+thresholds reach JavaScript via `wp_localize_script()` from the same constants
+the server enforces, so the two cannot drift apart.
+
+The verdict is applied with `setCustomValidity()` on the password field rather
+than by disabling a button: the form has up to three submits plus a "Next" that
+already gates on `checkValidity()`, and an invalid field stops all of them
+without any needing to know why. zxcvbn's dictionary loads asynchronously, so
+the gate stays open until it arrives — the server is the check that always runs.
+
 ## Registration Questions (signup step two)
 When the studio has configured **account-scope** registration questions
 (**Offerings → Questions → "Account signup"**, see `registration-questions.md`), the