Hash the plaintext, not the encrypted bytes, in verify --deep (closes #131)

Deep verification's final blob-integrity check hashed the encrypted
downloaded bytes with a single SHA256 and compared that to the blob's
remote name, which is the double SHA256 of the plaintext
(blobgen.Writer.Sum256). The two can never be equal, so verify --deep
reported every healthy blob as "blob hash mismatch". The per-chunk and
blob-existence checks were correct; only this final comparison was wrong.

It now hashes the decompressed plaintext as chunk verification streams it
and compares its double SHA256 to the blob name.

Added a test that backs up a real snapshot, deep-verifies it (which fails
before this fix), then flips a byte in one stored blob and confirms deep
verification then fails.

Model: opus-4-8

TODO.md

@@ -25,6 +25,16 @@ release" is exactly the contradiction
 
 # Completed Steps
 
+- 2026-09-21: Fixed `verify --deep` reporting healthy snapshots as
+  corrupt. Its final blob-integrity check hashed the encrypted
+  downloaded bytes with a single SHA256 and compared that to the blob
+  ID, which is the double SHA256 of the plaintext, so the two could
+  never match. It now hashes the decompressed plaintext and compares the
+  double SHA256. Added a test that backs up a real snapshot, deep-verifies
+  it, then flips a byte in one stored blob and confirms deep verification
+  then fails
+  ([issue #131](https://git.eeqj.de/sneak/vaultik/issues/131)).
+
 - 2026-09-21: Made `snapshot create` VACUUM the per-snapshot metadata
   database through the `modernc.org/sqlite` driver instead of shelling
   out to the external `sqlite` command-line binary (issue #120). A