Check downloaded originals against their recorded content hash (closes #68)

downloadFile, shared by quak get, the content cache and backup, hashes
the decrypted bytes (unkeyed BLAKE2b-512, standard base64) and stores
nothing on a mismatch, failing with an error naming the file ID. A live
photo ZIP is unpacked as it streams with fflate's Unzip, in small
slices so memory stays bounded however far an entry expands, and its
image and video hashed separately as <imageHash>:<videoHash>.
decryptFile reads the older imageHash/videoHash fields for live
photos. A file with no recorded hash is stored unchecked.

Model: opus-5-5

src/library/content.ts

@@ -15,12 +15,12 @@
 // Integrity. The reused streaming decrypt is the enforced guarantee: every
 // chunk is authenticated and the writer renames the file into place only once
 // the stream ends on TAG_FINAL, so a truncated or corrupt fetch throws and
-// nothing is stored. On top of that this module refuses to record a stored file
-// that came out empty. The design also asks for a content-hash comparison
-// against `FileMetadata.hash` (with a `fileSize` fallback); that is deferred —
-// see the PR — because the exact hash construction cannot be confirmed against
-// the repo's fixtures and `FileBlob.size` is the encrypted object size, not the
-// decrypted length this layer has.
+// nothing is stored. For an original whose metadata records a content hash
+// (`FileMetadata.hash`), the writer also hashes the decrypted bytes and stores
+// nothing if they differ, failing the fetch with an error naming the file. An
+// original with no recorded hash is stored unchecked, as the upstream client
+// does; thumbnails have none. On top of that this module refuses to record a
+// stored file that came out empty.
 
 import { existsSync, statSync } from "node:fs";
 import {