feat(backups): design opt-in stopped and multi-volume Restic recovery #801

Follow-up to #720 and the first-step consistency/coverage metadata in #767. The maintainer explicitly deferred automatic stop/copy/restart policy and multi-volume Restic copies in #720 (comment) because stopping running games changes availability.

The first step records what the current primary-volume capture actually includes. This issue tracks the remaining recovery behavior; it is not authorization to change default availability or claim cross-volume atomicity.

Scope to design:

• An explicit opt-in stopped backup policy: acquire the shared lifecycle owner, stop gracefully, prove workload/writer drainage, copy, then restore only the prior allowed power intent. Define cancellation, operator restart, failure and administrator-intervention behavior before implementation.
• Multi-volume Restic capture and restore using named roots tied to the capture-time manifest, including primary data, required extra data and separate loader/mod claims. Rebuildable and unclassified volumes need explicit handling, with recovery prerequisites visible before destructive restore.
• Restore preflight that validates selected volume identities/layout and surfaces missing required volumes without silently redirecting paths after template changes.
• Clear CSI limits: independent per-volume snapshots must not be described as an atomic application recovery point without a supported coordination mechanism.

Acceptance should include CI fixtures that round-trip a primary world and required extra volume, prove rebuildable-volume behavior, preserve user suspend/idle intent, and exercise stop/copy/restart failures under the exclusive owner from #718/#760. Preserve the worker-drain, original-Pod cleanup and deadline contracts from #716/#766 and #717/#719/#772.

Keep the existing compatibility default until the availability policy and recovery contract are reviewed.