Mirror CMP pending-confirmation registration and allauth email verification (68789580)

Start by reading AGENTS.md and the linked specs, then await the landed CMP intake 4169043a contract and report before mirroring. Extend accounts/services/email_verification.py and send_registration_confirmation_mail for pending/confirmed states, typo/MX checks, resend. Done means all owner acceptance criteria pass: unit and Playwright tests green, migration safe, dashboard resend shown, DEV deployed before prod.

Outcome and authority

Mirror the primary CMP email-confirmation behavior for course registration and allauth signup, with clear pending/confirmed states, correction/resend, typo/MX validation, member visibility, and migration safety. Hub intake 68789580-eb52-4b27-8d3b-355befb5e557; CMP intake 4169043a is primary. Do not change which registration form is canonical.

• Agent notes
• Development process
• Course registration
• Email boundary
• Security/privacy
• Verification strategy
• Selective verification

The exact owner acceptance criteria below control this bounded mirror. These references do not authorize unrelated account/profile or registration redesign.

Repository findings and scope

At base 35a023da73e9f61173f82e273eea8c001b11830c, accounts/services/email_verification.py already uses allauth EmailAddress, EmailConfirmationHMAC, and the account_confirm_email route. course_management.package_mail.send_registration_confirmation_mail incorporates this verification link into the existing package-mail message rather than creating a separate pipeline. Extend and document that implementation as requested. Website ACCOUNT_EMAIL_VERIFICATION is currently none; allauth signup currently uses the existing signup template. Implement only the explicitly requested confirmation behavior, without using this task to redesign authentication.

The website's existing CourseRegistration.status represents operator approval (pending means pending review). Email ownership confirmation is a separate requirement: preserve the existing approval semantics and coordinate with the application-notification mirror rather than silently making confirmation approve an application or making review approve an email address. The landed primary contract must settle the precise representation and transitions; do not invent a new verification model.

Typo suggestions must match the primary and remain suggestions with its correction semantics. The owner distinguishes a conclusive absent/null MX result (reject) from lookup failure/timeout (safe log and allow registration to continue); preserve that distinction with bounded lookup time and no address/DNS-detail leakage in logs.

Dependencies and coordination

Implementation prerequisite: settled/landed CMP intake 4169043a, its exact commits, and /home/alexey/tmp/agent-reports/cmp-registration-confirmation-ui-2026-10-24.md. At intake inspection, the report was absent and the primary candidate uncommitted in /home/alexey/git/cmp-regconfirm; that was not an accepted handoff. Record its final SHA/contract before mirroring, including typo semantics, pending/confirmed transitions, correction, resend throttling, and migration applicability. Read-only preparation may proceed while it settles.

Coordinate overlap in registration confirmation mail and post-submit templates with application-notification issue #471 and the registration contacts hook with #470. Preserve approval-specific copy, existing consent, recipient identities, and sibling work. Sibling landing requires fresh-main integration and the intake's rebase before every push.

Non-goals

No canonical-form decision, approval-policy change, new parallel verification model, second confirmation-mail pipeline, unrelated profile/authentication redesign, data deletion, real-user email, sensitive logging, shared git stash, or PR. The requested data migration preserves applicable existing registrations/accounts; it does not grant authority to manufacture unrelated verification evidence or alter historical consent.

Owner acceptance criteria (unchanged)

• Course registration and allauth signup show “check your inbox” with the submitted address, explain that clicking the confirmation link is mandatory, and offer “wrong email? fix it” and rate-limited resend.
• Registration remains pending confirmation until the link is clicked; confirmation is idempotent; expired/invalid links show a clear page with resend. Extend accounts/services/email_verification.py, reusing allauth EmailAddress and account_confirm_email inside send_registration_confirmation_mail; do not create a parallel model or mail pipeline. Confirmation emails use Relay. Document the existing implementation in the delivery report.
• Match CMP’s typo suggestion list and semantics, including hmail.com, gmial.com, gmai.com, gmail.co, gmail.con, yahooo.com, hotmial.com, and outlok.com. Reject domains without MX, including null MX. Bound DNS lookup time; log failures/timeouts without blocking registration.
• Dashboard/profile shows pending registrations/email and a resend button.
• A data migration preserves existing registrations/accounts as confirmed/verified where applicable.
• Copy and behavior match the settled primary report/commits.
• Unit coverage includes typo suggestions, MX/null MX, non-blocking DNS failure/timeout, pending-to-confirmed transition, tokens, resend, correction, and migration. Browser coverage exercises registration, pending page, confirmation link, confirmed state, and dashboard resend. Existing suite passes.
• Deliver from a fresh origin/main worktree; rebase on fresh origin/main before each push; push HEAD:main without a PR; clean up the branch/worktree. Follow AGENTS.md, use uv, preserve sibling changes, and never stash shared worktrees.
• Deploy DEV before production and report source SHAs and CI/deploy run IDs. No data deletions, real-user emails, or sensitive logging. Any live test email uses only the owner-authorized test recipient.

Verification scenarios and handoff

Django/integration: exercise the exact requested typo list, absent/null MX, bounded non-blocking DNS failure/timeout, pending-to-confirmed transition, valid/idempotent/invalid/expired tokens, rate-limited resend, wrong-address correction, and migration behavior. Reuse allauth ownership evidence and the existing Relay mail path. Preserve operator-review state while checking email confirmation. Existing baseline tests are evidence of current behavior, not acceptance of the new contract.

Browser: follow registration -> check-inbox/pending page -> confirmation link -> confirmed state -> dashboard/profile resend, including wrong-email correction and expired/invalid-link recovery. Inspect process-required desktop/mobile screenshots of the changed states and run the applicable Playwright tier from the exact verification plan.

Operations: record the accepted primary contract, source SHAs, required exact-base/head verification evidence, DEV-before-prod CI/deploy run IDs, test-only live verification, and task worktree/branch cleanup. The engineer hands off an uncommitted frozen candidate; independent tester PASS precedes final PM acceptance.