quak backup --verify re-hashes stored originals and downloads again any that do not match (closes #168)

`--verify`, or `lib.backup({ verify: true })`, hashes each original already
at its save path as the download check does, streamed, a live photo as
`<imageHash>:<videoHash>`. A mismatch is logged, removed and fetched again in
the same run; a failed fetch goes into `failures.json`. A file with no
recorded hash counts as unchecked. The result, the summary and `--json` gain
`verified`, `mismatched` and `unchecked`.

Judgement call: a stored original that cannot be read for hashing is recorded as failed and left in place.
Judgement call: the summary prints the three counts only with `--verify`.
Judgement call: the README's `BackupOptions` list does not name `verify`, to stay clear of #178's edit of that paragraph; Backup layout documents it.

Model: opus-5-5

TODO.md

@@ -25,6 +25,15 @@ declares one.
 
 # Completed Steps
 
+- 2026-10-06: `quak backup --verify` and `lib.backup({ verify: true })` hash
+  each original already at its save path as the download check does, streamed, a
+  live photo as `<imageHash>:<videoHash>` (issue 168). One that does not match
+  the content hash its metadata records is logged, removed (both files of a live
+  photo) and downloaded again in the same run; a failed download goes into
+  `failures.json`. One with no recorded hash is left alone. The result, `--json`
+  and the summary gain `verified`, `mismatched` and `unchecked`. Without
+  `--verify` nothing is hashed.
+
 - 2026-10-06: `quak backup` writes each original's EXIF, XMP and dimensions into
   the file's JSON as `imageMetadata`, what `backup-metadata --exif` records
   (issue 167): for a live photo from its image, for a video nothing, and `{}`