Delete the authenticated consumer's account (GDPR Article 17 erasure)

Hard-deletes the SESSION-AUTHENTICATED consumer's account: the api_consumers row plus everything that cascades from it (API keys, delegations, approval tokens, idempotency keys, saved profiles, subscriptions and their pending webhook queue), then the backing auth identity. The deletion target is ALWAYS the session-resolved consumer — a request body is never read on this path, so a body-supplied id or email is inert (the operator-run twin with an explicit target lives outside this spec at /api/admin/erase-consumer). Sequence is load-bearing: a pre-delete audit record is written first (append-only, survives the erasure), the database erasure then runs as ONE transaction via the delete_consumer_cascade RPC, and the auth identity is removed LAST — so a failure at any step can never strand a half-deleted account silently. Idempotent: deleting an already-deleted account returns a clean success (consumer_found: false), never a 500. Immutable audit records (audit_log, api_audit_log, risk_pattern_hits, webhook_deliveries and similar append-only tables) deliberately survive with a reference to the erased account for integrity; where such a record holds a NOT NULL foreign key to one of the account's API keys or subscriptions, that key/subscription row is retained in a revoked, tombstoned form (a SHA-256 hash with no personal data) rather than deleted. As the final deletion step the anonymize_consumer routine scrubs the retained references INLINE — the account's consumer id and any personal payloads on those forensic records are nulled or tombstoned so the retained rows no longer identify the account (reported by the anonymized field; the records themselves survive for legal/forensic integrity). Inline rate limit 5/hour per consumer, fail-CLOSED.