Return an error, not a panic, on a malformed snapshot database (closes #231)

Restore cut chunk hashes from the snapshot database to 16 characters
for its error messages, so a shorter hash panicked. Those messages now
use shortHash. Under --verify, a file_chunks row with no chunks row was
dereferenced, and the chunk size from the database was allocated in
one piece, so a negative or huge size panicked. A missing row is now an
error, a negative size is rejected, and each chunk is hashed by
streaming it from the restored file.

A restored file shorter than its chunks now fails verify as a short
read instead of an unexpected EOF.

Model: opus-5-5

TODO.md

@@ -22,6 +22,15 @@ the tag exists and is exercised; what is left is merging `next` to
 
 # Completed Steps
 
+- 2026-10-06: Made restore return an error instead of panicking on a
+  malformed snapshot database
+  ([issue #231](https://git.eeqj.de/sneak/vaultik/issues/231)). A chunk
+  hash shorter than 16 characters crashed the error message naming it,
+  and `--verify` dereferenced a missing `chunks` row and allocated
+  whatever chunk size the database gave. Those messages now go through
+  `shortHash`, a missing row is an error, and `--verify` rejects a
+  negative size and hashes each chunk as a stream.
+
 - 2026-10-06: Made `s3://bucket/prefix` and `s3://bucket/prefix/` the same
   destination ([issue #222](https://git.eeqj.de/sneak/vaultik/issues/222)).
   The S3 client put the prefix directly in front of each key, so a prefix