p2 · Auth token flow edge-case E2E

TL;DR

Extend Playwright coverage beyond happy paths for password reset and email verification tokens: reuse, expiry, forged token, and (after resend UI ships) resend verification.

Description

• Problem: tests/e2e/password-reset.spec.ts and tests/e2e/email-verify.spec.ts cover the main flows only. Server actions already reject expired/used/invalid tokens; regressions are unguarded.
• Context: Spun out from [[Projects/personal-finance-notion/backlog/done/p0-c1-password-reset|C1]] and [[Projects/personal-finance-notion/backlog/done/p0-c2-email-verification|C2]] after marking those items done.

Acceptance criteria

• Password reset: reuse same reset link → error UI; expired token (fixture or clock mock) → error; garbage token → error
• Email verify: reuse verify link → error; expired token → error; garbage token → error
• Resend: after [[Projects/personal-finance-notion/backlog/p1-email-verification-resend-ui|resend UI]], guest spec: resend → second email-verify captured
• All specs use POM + email stub (tests/utils/email-stub.ts); no raw selectors in specs

Implications

If skipped

• Token validation bugs in resetPassword / verifyEmail can ship unnoticed; users see broken reset/verify with no automated regression signal.

Why this priority

• p2 — quality gate only; server logic and happy-path E2E exist. Regressions hurt users but are caught manually until this ships.

When shipped

• Auth token handlers stay aligned with audit §verification scenarios without re-opening C1/C2 backlog items.

Dependencies

• Resend-path case depends on [[Projects/personal-finance-notion/backlog/p1-email-verification-resend-ui|p1 resend UI]] (can land other cases first).

Links

• App repo: tests/e2e/password-reset.spec.ts, tests/e2e/email-verify.spec.ts, src/lib/actions/passwordReset.ts, src/lib/actions/emailVerification.ts