Persist durable event consumer delivery state

docs/AUDIT_TRACE_CONTEXT.md

@@ -93,12 +93,24 @@ Commands and events are separate concepts:
   be written to the audit outbox before delivery.
 
 `govoplan_audit.backend.outbox.SqlAuditOutbox` persists platform events in
-`audit_outbox_events`. Dispatchers can later call
-`dispatch_pending_platform_events()` to publish pending events and record retry
-state. The outbox payload stores the full governed event envelope:
+`audit_outbox_events` and one durable state row per allowlisted consumer in
+`audit_outbox_deliveries`. Dispatchers supply stable consumer IDs and
+idempotent handlers. Consumer work and its delivered marker share one database
+transaction; retries reuse the stable `<event-id>:<consumer-id>` delivery key.
+Bounded failures are quarantined instead of retried forever. The outbox payload
+stores the full governed event envelope:
 correlation/causation ids, actor, tenant, subject, resource, classification,
 module id, event id, type, and payload.
 
+Public and internal events may use an allowlisted subscription directly.
+Confidential and restricted subscriptions additionally require a persisted
+policy-decision reference. Operators can inspect delivery metrics at
+`GET /api/v1/admin/audit/event-delivery/metrics` and replay a retrying or
+quarantined delivery with a reason through
+`POST /api/v1/admin/audit/event-deliveries/{event_id}/{consumer_id}/replay`.
+Replay itself is written to the audit log. Successful envelopes are subject to
+configured retention; quarantined evidence is not removed automatically.
+
 Application code should enqueue or publish facts only after the state change
 they describe is known. Long-running operators and installers should model
 requested work as commands first, then emit facts as events as each step