feat(activation): verify-email resend endpoint + recovery links (anti-enumeration)

[Deesmo]

Problem

Comments in verification.ts/agent.ts/agents.ts have referenced /v1/verify-email/resend since the verification gate shipped — but the endpoint was never built. A user whose 30-minute verify token expires (or whose email never arrives) is permanently stranded: 75 pending credits they can never activate, and no recovery path. That user will never convert.

What this adds

POST /v1/agent/verify-email/resend — accepts {email} (JSON or urlencoded form).

• Anti-enumeration by construction: ALWAYS the same neutral 200 body ("If an unverified account exists for that email…") whether the account exists, is already verified, or is inside the resend cooldown. JSON for API clients, a script-free HTML page for browser form posts (Accept-negotiated). Internal DB errors also return the neutral 200 — no availability oracle.
• Rate limit: 3/hour per normalized email + IP (same in-process Map pattern as ipSignupCounts; gmail dot/plus aliases share one budget), counted before any DB read so the 429 can't leak existence either. The existing /v1/agent authLimiter (20/15min/IP) still applies on top.
• Cooldown: if the current token was minted <2 min ago the resend is a silent no-op — the endpoint can't be used as a mail cannon inside the hourly window.
• Internals: new reissueEmailVerification() rotates ONLY verifyToken/verifyTokenExpiry and re-sends the email with the account's CURRENT pendingCredits.

⚠️ Why not just call issueEmailVerification() again (as the stale comments implied): that function is the signup grant-splitter. On a non-fresh agent the SignupIdentity claim is already consumed → gated=0 → it would SET pendingCredits to 0, wiping the user's 75 gated credits. The resend path deliberately never touches any credit field, and the tests assert that.

Recovery links

• Expired/invalid-link error page (verifyEmailHtml.ts): "Didn't get the email — or did the link expire?" plain-HTML form (zero JavaScript, per the emailed-link page rules) posting to the new route; browser gets a neutral script-free confirmation page.
• Signup success card (signupHtml.ts): verify note + "Didn't get the email? Resend it" link — fires only on explicit click, mirrors the server's neutral message via textContent.
• Stale comments in verification.ts / agent.ts / agents.ts now point at the real route.

Tests

New tests/verify-resend.test.mjs (13 tests, wired into npm test):

• anti-enumeration: byte-identical 200 bodies for unknown email / verified account / cooldown no-op
• happy path: expired token → single write rotating only token fields; asserts credits/pendingCredits/emailVerified are never written
• no-token unverified account (failed signup setup) is recoverable
• rate limit: 4th request → 429 pre-DB; per-email key (no blanket IP ban); gmail alias normalization shares the budget
• browser form post → neutral, script-free, submitted email never reflected
• garbage email → 400; internal DB error → neutral 200

Verification

• npm run build exit 0
• node tests/verify-resend.test.mjs — 13/13 pass
• Adjacent suites re-run green: verify-activation, signup-firstcall, oauth-signup-cta, pages, critical-regressions (all exit 0)

Council constraints respected: conversion/stop-bleed only, no payment-rail changes, nothing auto-fires, all copy factual, no user input reflected into HTML.

🤖 Generated with Claude Code

---

Note

Medium Risk
Touches signup/verification and outbound email with enumeration and abuse controls; credit fields are intentionally untouched but behavior is security-sensitive.

Overview
Adds POST /v1/agent/verify-email/resend so users with expired or missing verification emails can get a new link without calling signup-time issueEmailVerification() again (that path would wipe pendingCredits on existing accounts).

The handler always returns the same neutral 200 (JSON or script-free HTML via Accept), with 429 only from an hourly per normalized-email+IP limiter that runs before any DB read. reissueEmailVerification() rotates only verifyToken / verifyTokenExpiry, enforces a short mint cooldown, and re-sends mail using the current pending balance.

Recovery surfaces: a no-JS form on the invalid-link page, a click-only resend on the signup success card, and a neutral “check your inbox” page for form posts. tests/verify-resend.test.mjs is wired into npm test.

^{Reviewed by Cursor Bugbot for commit e4f6e12. Configure here.}

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Gmail alias resend lookup fails
  • reissueEmailVerification now resolves the agent via the same normalized-identity SQL as enforceSignupLimits (Gmail dot/plus/googlemail aliases match the stored row) and sends to the stored Agent.email, verified end-to-end against a local DB and covered by a new regression test.

_{You can send follow-ups to the cloud agent here.}

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit e4f6e12. Configure here.}

[cursor]

Gmail alias resend lookup fails

High Severity

The reissueEmailVerification function uses findUnique on the submitted email, but the email stored during signup might be a non-canonical form (e.g., Gmail dot/plus aliases). This mismatch prevents finding the agent, causing the resend to silently fail (returning a neutral 200) and leaving pending credits locked for affected users.

 

^{Triggered by learned rule: SignupIdentity queries must use normalizeEmailIdentity, not plain toLowerCase}

^{Reviewed by Cursor Bugbot for commit e4f6e12. Configure here.}