Implement PostgreSQL production store path

Add the PostgreSQL backend, migration and stopped-write transfer tools, lease-aware deployment manifests, tenancy declarations, and shared conformance coverage. Persist grouping mutations in durable stores and separate process liveness from database readiness.

docs/data-retention-policy.md

@@ -0,0 +1,50 @@
+# Tenant registry retention and deletion policy
+
+Status: implemented policy for the current data model; reviewed 2026-08-18.
+
+This policy is the authoritative `deletionPolicyRef` for tenant-engine. It
+separates business-record retention from PostgreSQL backup retention; a backup
+window never silently decides when an authoritative tenant fact may be erased.
+
+## Primary records
+
+Tenant records are canonical registry facts. `retire` is reversible and is not
+deletion. Tenants, plan assignments, grant/revocation history, domain events
+and guardrail changes are retained without an automatic expiry while the
+registry remains authoritative. There is deliberately no hard-delete API.
+
+Contact email and display name are the only mutable person-attributable fields.
+An authorized erasure request is an attended maintenance change: remove or
+replace those fields while preserving the tenant id, identifier, lifecycle,
+version and audit trail needed to explain prior authorization decisions. Until
+that operator procedure has run, tenant-engine makes no claim that retirement
+erases personal data.
+
+Idempotency receipts currently have no automated primary-store expiry. They
+therefore share the indefinite primary retention above. Introducing an expiry
+requires a forward-only migration plus proof that the maximum client retry
+window is shorter; it must not be inferred from the backup window.
+
+## Copies outside the primary database
+
+- `platform-pg` physical backups and WAL have a 30-day retention window shared
+  across all databases on the cluster. After a primary-row redaction or future
+  deletion, physical copies can remain recoverable for at most that declared
+  window, subject to a successful and verified backup-policy deployment.
+- The per-consumer encrypted logical export is retained for 30 days. Its
+  declaration is `rapp-postgres/consumers/tenant-engine.yaml`.
+- Scratch restores are operator-created evidence environments and must follow
+  the platform scratch-restore policy; they are not production read replicas.
+- The stopped SQLite PVC retained during cutover is a rollback copy. It must be
+  access-restricted, named in the cutover record, and destroyed only after the
+  PostgreSQL soak and rollback decision. It is not a second live source of
+  truth.
+
+## Assurance position
+
+Publishing this policy does not raise tenant-engine above R0 by itself. The
+service has policy-driven backup-copy windows, but no automated primary-row
+expiry or verified personal-field erasure workflow. `tenancy.yaml` therefore
+keeps current R0 and target R2. A customer-facing “deleted data is gone” claim
+is prohibited; any future claim must disclose the effective erasure horizon
+and be backed by dated deletion plus backup-expiry evidence.

docs/tenant-lifecycle-api.md

@@ -35,6 +35,11 @@ Reactivation restores the tenant's ability to receive new grants and plan
 changes. It deliberately does **not** resurrect revoked grants or invent plan
 state — those stay exactly as retirement left them.
 
+Retention and erasure semantics are normative in
+`docs/data-retention-policy.md`. In particular, retirement does not erase
+contact data, and the 30-day PostgreSQL backup window is a copy horizon rather
+than a primary-record expiry rule.
+
 ---
 
 ## Immutability