Offer the backup, and then the rebuild, when the index turns out to be damaged

NFR-R6 asks for an integrity check at startup and two offers behind it, and
none of it existed. `PRAGMA integrity_check` appeared nowhere in the tree,
`Catalog::open` was `open` → `configure` → `migrate` → `backfill` and nothing
else, and corruption therefore surfaced as whatever rusqlite error the first
unlucky query happened to produce — "database disk image is malformed"
attached to a thumbnail refresh, elided into a 34px banner, over an empty
grid saying "No images found · Check the library folder". Two messages that
disagreed, and no way forward but deleting catalog.sqlite by hand.

The property that makes the second offer real was already here and load-
bearing: the catalog is an index, not a source of truth, rebuildable from
sources plus sidecars (invariant §5.2.4, cited by schema.rs, trash.rs and
lib.rs). And sync.rs already knew how to take a coherent snapshot of a WAL
database. What was missing was the check, the type, and the conversation.

Four pieces:

**The type.** `CatalogError::Corrupt`, and — the part that makes it worth
having — a hand-written `From<rusqlite::Error>` that classifies rather than
wraps. `SQLITE_CORRUPT` and `SQLITE_NOTADB` become `Corrupt` wherever they
arise, so a background job that trips over the damage first reports the same
thing the startup check would have. `SQLITE_IOERR` and `SQLITE_BUSY`
deliberately do not: a dropped network mount is a different problem, and
telling someone to rebuild their index would be a wrong answer delivered
confidently.

**The check.** `Catalog::open_verified`, `quick_check` before the open rather
than after, because opening runs migrations and a damaged catalog with an
intact header would otherwise have structure rewritten on top of structure
that is already wrong. Bound to `open_verified` and not to `open`: the check
reads every page, which is affordable once at startup where a user can answer
a question, and not affordable on the dozens of opens a session's background
tasks make.

**The backup.** NFR-R2's second clause, taken between `configure` and
`migrate` in `Catalog::open`. A migration is the one routine operation that
rewrites table structure, so it is the likeliest way this file becomes
unreadable, and it is the last moment the pre-migration state exists to be
copied. Three generations, through SQLite's backup API after a TRUNCATE
checkpoint — never `fs::copy`, which on a WAL database backs up a state older
than the catalog and possibly torn. A failure to take the copy is logged, not
raised: a full disk must not be what makes a library unopenable.

**The conversation.** The first line of the dialogue is that the photographs
and the edits are safe, before the diagnosis, because that is the question the
user is actually asking. Then the two offers, which are *not* interchangeable
and are not presented as if they were: a restore keeps collections, and a
rebuild cannot, because a manual collection is a set of images assembled by
hand and nothing in the filesystem records it (docs/catalog.md §8.1). The
labels say so, and the rebuild does not take the affirmative styling while a
restore is on the table.

One thing that is a fix rather than a feature: `show_catalog_now` now gates
the scan. `Catalog::open` succeeds on a file whose header survived, so the
scan that used to start immediately afterwards would write folder ETags and
image rows into damaged pages in the seconds while the user was still reading
the question — turning a file that had a backup into one where the backup is
the only copy left.

Restore also deletes the damaged catalog's `-wal` and `-shm`. That step is
easy to leave out and fatal to leave out: a journal belonging to the old file,
sitting beside the new one under the same name, is replayed into it on the
next open. That is not a restore, it is a fresh corruption with the evidence
gone.

Tested by corrupting a fixture catalog — 500 images and a collection, then
every page past the second overwritten — and driving both branches. The
restore is asserted on the collection, because a collection is precisely what
distinguishes the two paths; the rebuild on the damaged file being kept and
the next open producing an empty catalog at the current schema. Plus the
`SQLITE_NOTADB` presentation, a damaged backup being refused rather than
installed, and a v1 catalog whose pre-migration backup comes back reading
v1 rather than v11.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

core/dr-catalog/src/lib.rs

@@ -21,6 +21,7 @@
 //! - [`runner`] — the thing that drains it, driven by whoever owns the thread
 //! - [`trash`] — soft delete to a folder, then permanent delete
 //! - [`merge`] / [`sync`] — cross-device merging of collections and keywords
+//! - [`recovery`] — backups, and the two offers made when this file is damaged
 //!
 //! # The one thing everything is designed around
 //!
@@ -47,6 +48,7 @@ pub mod keywords;
 pub mod merge;
 pub mod query;
 pub mod rating;
+pub mod recovery;
 pub mod runner;
 pub mod scan;
 pub mod schema;
@@ -65,6 +67,7 @@ pub use keywords::{Coverage, Keyword, KeywordId, SelectionKeyword};
 pub use merge::MergeReport;
 pub use query::{Query, Sort};
 pub use rating::{Judgement, MAX_RATING};
+pub use recovery::Backup;
 // Not `runner::Budget`: `cache::Budget` already owns that name here and
 // means something else entirely (bytes on disk, not jobs in a slot).
 // Callers spell the work budget `runner::Budget`, where it is unambiguous.
@@ -222,9 +225,23 @@ pub struct Catalog {
 
 impl Catalog {
     /// Open or create a catalog, migrating it forward if needed.
+    ///
+    /// Does **not** verify the file — see [`Self::open_verified`], and
+    /// [`recovery`] for why the check is bound to startup rather than to every
+    /// open. Damage this trips over on the way past is still reported as
+    /// [`CatalogError::Corrupt`] rather than as a stray SQLite error.
     pub fn open(path: &Path) -> Result<Self, CatalogError> {
         let conn = Connection::open(path)?;
         schema::configure(&conn)?;
+        // NFR-R2, and the reason it is *here*: a migration is the one routine
+        // operation that rewrites table structure, so it is the likeliest way
+        // this file becomes unreadable — and afterwards there is no
+        // pre-migration state left to copy. A failure to take the copy is
+        // logged rather than raised: a full disk must not be the thing that
+        // makes a library unopenable.
+        if let Err(e) = recovery::backup_before_migration(&conn, path) {
+            log::warn!("could not back up before migrating: {e}");
+        }
         let from = schema::migrate(&conn)?;
         // A migration adds a column; it cannot know what the value should be
         // for rows that already existed. Backfilling on open is what stops
@@ -235,6 +252,26 @@ impl Catalog {
         Ok(Catalog { conn })
     }
 
+    /// TRACES: NFR-R6
+    /// Open a catalog, checking the file first.
+    ///
+    /// What startup calls. On [`CatalogError::Corrupt`] the caller has a user
+    /// in front of it and must make the two offers [`recovery`] describes,
+    /// rather than reporting a SQLite message on a banner and carrying on into
+    /// a scan that would write into the damage.
+    ///
+    /// Checked *before* opening rather than after, because opening runs
+    /// migrations: a damaged catalog that happens to have an intact header
+    /// would otherwise be migrated — rewriting structure on top of structure
+    /// that is already wrong — before anybody asked whether it was sound.
+    pub fn open_verified(path: &Path) -> Result<Self, CatalogError> {
+        // A catalog that is not there yet is not damaged; `open` creates it.
+        if path.is_file() {
+            recovery::check_file(path)?;
+        }
+        Self::open(path)
+    }
+
     /// An in-memory catalog, for tests and for a throwaway import preview.
     pub fn in_memory() -> Result<Self, CatalogError> {
         let conn = Connection::open_in_memory()?;