Recovery — capture and restore one consistent installation #44

Planning representation replaced — 6 November 2026. The accepted Restore and controlled evolution outcome is retained in #62. Reopen one bounded task when selected. This closure does not mean the capability is complete or cancelled. The original scope and evidence below remain preserved; current selected work starts at #52.

Prove one coordinated backup/restore path on an isolated test installation.

Starting point: Current delivery: Btrfs layout preparation does not provide a coordinated checkpoint.

First working slice

• Close admission and quiesce writers; bind source/artifact, schema, Settings, extension and storage identities in one manifest.
• Capture PostgreSQL at a supported consistency boundary plus required files using one named driver; seal only a complete capture and handle interrupted freeze.
• Restore into an inactive target, validate the manifest and reconcile parked/in-flight work before opening admission.
• Verify corrupted/mismatched capture refusal and uncertain external effects remaining blocked; record the supported restore limits.

Connections: Builds on #2/#18 and coordinates #22/#8. Includes #23's artifact custody when configured; payments in #32 cannot be rewound by restoring local state.

Later: Additional drivers, retention automation, encrypted backups and broader recovery drills.

References: ADR 07 · ADR 06.

Contribution entry: Define a capture manifest or one mismatch/restore refusal case.
Open decision: Select the first consistent capture driver and supported in-flight-work boundary.
Verification: Isolated PostgreSQL/filesystem restore drill. Shared contribution and touched-docs rules: #52.