Adopt recovery ledger for Campaign builds

docs/CAMPAIGN_BUILD_RECOVERY.md

@@ -0,0 +1,26 @@
+# Campaign Build Recovery
+
+Campaign build is fenced per tenant and Campaign version. Before rendering or
+writing generated artifacts, Campaign commits a Core recovery operation with
+the canonical source and validation hashes, the runtime fence, and a reserved
+opaque object prefix. A repeated idempotency key can replay only a verified
+successful build; it cannot start a second active build.
+
+Generated EML and bounded print output are written to shared storage and checked
+for exact size and SHA-256 content. Campaign then commits its jobs and execution
+snapshot, compares the stored object and database manifests, and records
+verified success. A managed Files output makes the operation forward-recoverable
+because Campaign cannot undo a Files-owned artifact; object-only builds use
+explicit compensation.
+
+If the Campaign database transaction fails, Campaign deletes every object it
+recorded and verifies absence before recording recovered state. Failed deletion,
+an unavailable storage check, process loss, or superseded-object cleanup failure
+leaves a recovery-required operation visible in Ops. Do not retry such an
+operation as a normal build. Verify its checkpoint chain and reserved prefix,
+then reconcile it through the owning-module procedure. The orphan inventory
+reconciler tracked in Campaign issue 91 will automate that bounded inspection.
+
+No recovery checkpoint contains message bodies, recipients, credentials, or
+resolved provider secrets. Object keys remain restricted diagnostics rather
+than Campaign business data.