feat: govern shared campaign artifact storage

docs/CAMPAIGN_DELIVERY_RUNBOOK.md

@@ -134,6 +134,29 @@ production process manager. Repeat the worker-loss drill under the selected
 systemd, container, Kubernetes, or other production supervisor and the target
 Redis/SMTP infrastructure before deployment approval.
 
+## Shared Build Artifacts
+
+Generated EML is stored through Core's configured object-storage backend under
+opaque Campaign-owned keys. The job records expected byte size, SHA-256 digest,
+and Message-ID. A worker on another node must retrieve and verify those values
+before attempting delivery.
+
+- Do not expose object keys to ordinary campaign users or copy them into
+  business fields.
+- A build failure deletes objects written before the database transaction can
+  commit.
+- Retention clears metadata only after object deletion succeeds; an unavailable
+  backend leaves the reference in place for a later retry.
+- A hard process loss between object creation and metadata commit can leave an
+  orphan object. Reconcile only within the Campaign build prefix and verify that
+  no job references the object before deleting it.
+- Restore Campaign rows, object storage, and the encryption key to one
+  coordinated recovery point before resuming workers.
+
+For a scaled-runtime drill, build on one API replica, consume from another
+worker, compare the stored evidence, and inject storage failures during build
+and retention.
+
 ## Reporting Checks
 
 - Partial delivery must show accepted, failed, and unknown counts separately.