Fail closed on unreadable manifests instead of losing blobs (closes #157)

Prune learned which blobs are in use by reading every snapshot's
manifest, but merely logged and skipped one it could not download or
decode. Blobs referenced only by that snapshot then looked unreferenced
and were deleted, with a zero exit — and `snapshot create --prune` runs
this unattended. collectReferencedBlobs now errors, naming the remote
key, so prune deletes nothing and exits non-zero.

Manifest generation likewise skipped a blob whose lookup failed or was
missing, yielding a manifest short of what the snapshot needs; it now
fails. Deep verify only warned when the manifest omitted a database
blob; it now fails on any divergence. Docs corrected.

Model: opus-4-8

docs/REPOSTRUCTURE.md

@@ -145,10 +145,10 @@ An observer cannot determine:
 ## Pruning Safety
 
 The prune operation is safe because:
-1. It only deletes blobs not referenced in any manifest
+1. It keeps every blob listed in any snapshot's manifest and deletes only blobs that no manifest references
 2. Manifests are unencrypted and can be read without keys
-3. The operation compares the latest local DB snapshot with the latest S3 snapshot to ensure consistency
-4. Pruning will fail if these don't match, preventing accidental deletion of needed blobs
+3. If any manifest cannot be downloaded or decoded, prune deletes nothing and exits with an error, rather than treating that snapshot's blobs as unreferenced
+4. Prune requires exclusive access to the destination: running it during a concurrent backup can race a snapshot whose manifest is not yet written, so do not prune while a backup is in progress
 
 ## Restoration Requirements