Document audit quarantine for generated Compose packages

[jeremi]

Outcome

An operator whose Relay or Notary readiness fails because the durable audit chain is inconsistent can run the existing product-owned quarantine recovery safely from a generated Compose package, then prove readiness before restoring traffic.

This follows the product recovery delivered by #196 and #300. It is intentionally post-1.0 documentation and packaging work, not a new recovery mechanism or a general orchestration surface.

Design constraints

• Keep fail-closed readiness and the one-way unhealthy latch.
• Use the existing product-owned audit quarantine commands and durable audit volumes.
• Do not grant Registryctl audit-mutation authority.
• Do not expose secret values, source credentials, or serving-only network access to the recovery action.
• Keep Relay public, Relay consultation, and Notary ownership distinct.
• Generated Compose remains replaceable and manually adaptable outside Registryctl certification.

Definition of Done

• The generated RUNBOOK.md gives exact stopped-service quarantine commands for all three product lanes.
• Commands mount only the required audit/config inputs and run without serving traffic.
• The runbook explains the manual abort boundary, retained quarantine evidence, and backup implications.
• Exact state verification and /ready checks are required before traffic resumes.
• Tests prove the commands stay value-free and match the generated Compose model.

Non-goals

• Automatic repair or deletion of audit history.
• Generic incident orchestration.
• Multi-node or Kubernetes recovery.