🔒 GDPR export+erasure controller + /api/users/me/data routes + re-auth

[PierreBrisorgueil]

Reintroduce the user-facing erasure endpoint + route wiring, orchestrated over the provider registry (no static cross-module imports).

Scope — users.data.controller.js + routes

Erasure orchestration (DELETE /api/users/me/data):

1. Re-auth proof required (see re-auth hardening sub-issue) + strict rate limiter (limiters.auth) on the route.
2. Re-entrancy guard: in-flight erasure flag → concurrent DELETE = 409.
3. Resolve + snapshot axes ONCE: { soleOwnedOrgIds, sharedOrgIds } via memberships.
4. Write the ErasureRequest ledger doc BEFORE the first destructive call — a retry re-reads the snapshot (memberships are deleted mid-run; request-time re-resolution after a partial failure would silently skip org-axis providers).
5. Run validate() across ALL providers — any blocker aborts before any deletion (predictable blockers surface pre-destruction).
6. Phases: external + org-axis (sole-owned only) → user-axis → organizations/memberships → clear cross-refs (referredBy) → confirmation email (Art 12(3), terminal outward action) → UserService.remove LAST.
7. Response = erasure receipt (per-provider {removed, retained, messages}).

• REMOVE DELETE /api/users entirely (single erasure door; breaking note in MIGRATIONS.md). A deprecated-but-routable legacy route would remain a second door that still orphans data.
• usersExportProjection: exclude password, reset/verification tokens, lockout counters; strip OAuth tokens from providerData and additionalProvidersData.
• Routes /api/users/me/data (+ /me/data/exports wiring for the async export sub-issue): passport jwt + policy.isAllowed; moderate limiter on the export-request route (fan-out endpoint).

DoD

• Integration: phase order enforced; retry-after-mid-failure still runs org-axis providers (ledger snapshot); re-entrancy 409; legacy DELETE /api/users gone (404).
• /verify + /dev:verify-qa green.

Depends on: registry leaf v2, ErasureRequest ledger.

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

[PierreBrisorgueil]

Live gap surfaced by the 2026-06 audit (deep-validated HIGH) — folds into this issue's endpoint deprecation

users.service.js:191-192 deletes a sole-owner org via the bare OrganizationsRepository.remove({ _id: orgId }) — bypassing runOrganizationRemovedHandlers (which fires only via OrganizationsCrudService.remove). So on account deletion the registered org-removal handlers (tasks cleanup today; billing once added) never run → orphaned org-scoped data. The stale comment at L191 ("intentionally not deleted here") predates the orgRemoval.registry refactor.

This issue's plan deprecates DELETE /api/users in favour of /me/data erasure, which supersedes this path. Until that lands the live orphaning continues, so if a stop-gap is wanted: inline await runOrganizationRemovedHandlers({ organizationId: orgId, organization: { _id: orgId } }) before the repo remove.

Do NOT reroute through OrganizationsCrudService.remove — it double-runs the membership deleteMany AND regresses the null-safe co-member currentOrganization repair (users.service filters m.organizationId != null; crud.service uses remaining[0] unguarded).

Also flagged: latent twin organizations.crud.service.js:298 removeById (same bare-repo bypass, no prod caller today — delete or annotate). Source: June audit report, deep re-validation finding #3.

[PierreBrisorgueil]

🅿️ Parked with epic Node#3802 by the 2026-07-30 board audit (P3, out of the drain queue).