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

[PierreBrisorgueil]

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

Scope

• modules/users/controllers/users.data.controller.js — getData / deleteData / getMail.
  • resolveAxes(req) → { user, organizationIds } (resolve the user's orgs so org-axis providers can run).
  • getData: usersExportProjection(getBrut) + runDataExport → { user, ...data, _manifest }.
  • deleteData: require re-auth proof (DataErasureConfirm Zod schema + passwordHelper, password re-entry; OAuth-only accounts fall back to a short-lived confirmation token) → runDataErasure → clear dangling referredBy FK → UserService.remove last.
• Re-add GET/DELETE /api/users/me/data in users.routes.js (passport jwt + policy.isAllowed).
• Deprecate the legacy DELETE /api/users so there is a single erasure door (note in MIGRATIONS.md).
• usersExportProjection: exclude password, reset/verification tokens, lockout counters; strip OAuth accessToken/refreshToken.

DoD

• Integration test: export shape; erasure deletes children then the user doc; re-auth rejects a bad password.
• /verify + /dev:verify-qa green.

Depends on: GDPR registry leaf.

Created via /dev:issue