🔒 GDPR re-auth hardening — lockout wiring + rate limiters + OAuth confirm token

[PierreBrisorgueil]

Harden the re-auth step on the irreversible DELETE — close the password-oracle hole and give OAuth-only accounts a real path.

Scope

• Password path: the re-entry check on DELETE /api/users/me/data runs through the SAME failure accounting as sign-in — bad attempt increments failedLoginAttempts / triggers lockUntil — plus the strict limiters.auth rate limiter on the route. (Without both, a stolen session cookie turns the endpoint into an unthrottled password-guessing oracle.)
• OAuth-only path: POST /api/users/me/data/confirm issues a single-use, ~15-minute confirmation token, stored hashed on the user doc (same pattern as resetPasswordToken), delivered to the verified account email; DELETE accepts { confirmToken } as the re-auth proof. Token invalidated on use and on expiry; issuing route rate-limited.
• DataErasureConfirm Zod schema covers both proofs (password XOR confirmToken).
• GET/POST export routes get a moderate limiter (fan-out endpoints).

DoD

• Bad password on DELETE increments lockout counters; limiter returns 429 under burst.
• Confirm token: single-use, expiry, hashed-at-rest, wrong/reused token rejected.
• /verify green.

Depends on: export+erasure controller.

Created via /dev:issue · contract v2 2026-07-03