feat: add governed Campaign DSAR coverage

docs/CAMPAIGN_HANDBOOK.md

@@ -557,6 +557,30 @@ purpose, lawful basis, minimization, export control, and retention before the
 campaign starts; do not use Campaign as a substitute consent or address-master
 system.
 
+The Core data-subject-request workflow discovers Campaign through the optional
+`privacy.dsar.campaigns` capability. After the request's email, membership, and
+namespaced Campaign references have been independently authorized and
+corroborated, the provider searches only the effective tenant and isolates the
+matching recipient entries and jobs. Its JSON result includes safe Campaign,
+version, delivery-attempt, schedule, report-projection, share, import-mapping,
+attachment, and generated-artifact metadata. Generated EML bytes and paths,
+storage locators, delivery target snapshots, worker claims, idempotency
+material, credentials, secret-like values, and unrelated recipients are never
+embedded in that result. Authorized Campaign and Files review surfaces remain
+the source for content that cannot safely be copied into the DSAR case.
+
+Built, locked, published, terminal, delivered, or corrected records are
+retained with an explicit reason and continue through Campaign's configured
+retention and redaction process. Draft recipient content and user-owned
+attachment content require coordinated manual review because copies may span
+version JSON, jobs, generated messages, and managed files. The provider can
+idempotently revoke an active share aimed at the subject and delete the
+subject's personal recipient-import mapping profile. It does not rewrite
+delivery evidence, delete generated artifacts, or report derived Campaign
+counts as a separate store. Re-running an approved action is safe: already
+revoked or absent data is reported as unchanged, and tenant, subject, and row
+ownership are revalidated immediately before mutation.
+
 ### Audit and destructive actions
 
 Material authoring, validation, locking, review, queueing, send, retry,