Function verify_snapshot_chain 

pub async fn verify_snapshot_chain(
    conn: &Connection,
    ts: &str,
    archive_path: Option<&Path>,
    snapshots_dir: &Path,
) -> Result<ChainCheck>

Fold from genesis and compare against the composed answer (§5.5, T5.3, D-092).

The problem this exists for

crate::temporal::save_snapshot is written by write_final, which calls reconstruct — and reconstruct composes onto the previous snapshot whenever one is usable. So snapshot n is derived from snapshot n−1, and there is no periodic full fold anywhere in the chain. An error introduced at any link is copied forward indefinitely, and every subsequent read agrees with it, because they are all reading the same descendant.

The project’s own open item names the difficulty honestly: a full fold is exactly the cost snapshots exist to avoid, so this cannot run on every read. It is a scheduling problem, and this function is the thing to schedule.

It reports; it does not repair

Deliberate, and not merely conservative. Under Doctrine VI a snapshot is derivative and disposable, so the repair is delete the snapshots — one line, available to the caller, and correct without this function’s help. What the caller cannot get for themselves is the knowledge that the chain diverged, and silently rewriting the file would destroy the only evidence of a bug in composition. A divergence here is not a corrupt database; it is a wrong cache, and it means composition has a defect worth finding.

Cost

One fold from genesis over the whole log, plus one composed reconstruction. That is the expensive path by construction — see [crate::Database:: verify_snapshot_chain] for the handle-level entry point and the note on when to run it.