🔒 GDPR ErasureRequest ledger — write-before-destroy, replay-ready

[PierreBrisorgueil]

Durable erasure record — written before the first destructive call, survives the erasure, makes retry + restore-replay + accountability (Art 5(2)) possible.

Scope — modules/users (ledger model + repository)

• ErasureRequest model: { emailHash (salted, no clear-text identifier), requestedAt, completedAt, axesSnapshot: { soleOwnedOrgIds, sharedOrgIds }, providers: [{ key, status: pending|done|retained|failed, itemsRemoved, itemsRetained, messages }], retainedCategories: [{ key, ground, duration }] }.
• Written by the orchestrator BEFORE any provider runs; updated after each provider; kept AFTER the User doc is deleted (PII-minimal by design — hashed identifier only, never profile data).
• Retry support: an incomplete request re-runs from its snapshot (org list re-resolution is never needed twice — memberships may already be gone).
• Replay support: query requests newer than a given date → re-run their erasures (idempotent providers make this safe). This is the restore-time re-erasure mechanism the consumer guide documents for database backups.
• Excluded from the coverage gate via an explicit waiver (it IS the compliance record); never exposed through any provider.

DoD

• Unit: write-before-destroy ordering, per-provider status updates, survives user deletion, replay query.
• PII-minimal assertion (no clear-text email/name persisted).
• /verify green.

Depends on: registry leaf v2.

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