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