fix: let restore-backup finish a restore interrupted between renames

[xsmyile]

Finishes the first item of #129: with the database missing, an intact backup and a newest .schema1- that is a schema-1 database, restore-backup does the second rename and leaves every kept file as it is; any other state is refused.

[pullfrog]

Important

The recovery path can modify the kept database even when it refuses the restore; check its SQLite sidecars before opening it.

Reviewed changes Reviewed the interrupted-restore recovery path, refusal diagnostics, regression tests, and upgrade guidance.

• Recovery detection: Recognizes a missing database with a backup and exactly one timestamped schema-1 kept file.
• Restore completion: Validates backup integrity and original/backup sidecars, then shares the final rename and directory sync with normal restores.
• Tests and guidance: Adds five recovery tests and documents retry/manual-recovery behavior. All 15 restore tests pass; a temporary targeted reproduction confirmed the preservation issue below and was removed afterward.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using gpt-6.1-sol ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes Reviewed the kept-file preservation fix since the previous review, with the full recovery path as context.

• Refused kept-file sidecars: Checks for WAL, SHM, and journal files before opening the kept database.
• Made the recovery probe immutable: Prevents the schema check from writing the kept file or creating SQLite sidecars while retaining existing probe behavior for other callers.
• Added preservation coverage: Exercises a valid orphan WAL and verifies the precise refusal, unchanged backup/database/WAL bytes, and absence of a newly created SHM file.

All 16 focused restore tests pass. The previous preservation finding is addressed and its thread has been resolved.

  ^{｜ View workflow run ｜ Using gpt-6.1-sol ｜ 𝕏}