Store each hash as its raw 32 bytes in a BLOB column (closes #134)

The head, tail and content columns of the files table are BLOB NOT
NULL and hold the raw 32-byte SHA-256, half the size of the hex text,
in the table and in the files_signature index. The hash phase, the
records, report and trees carry each hash as a [sha256.Size]byte and
compare it with ==; nothing is hex-encoded. Reading a record whose
hash column is not 32 bytes is an error naming its path.

In the tests, testHash is a stand-in hash: a string's bytes padded
with zeros, so fixtures keep the sort order their strings give.

Judgement call: a hash of the wrong length is refused on reading,
not copied silently.

Model: opus-5-5

TODO.md

@@ -29,6 +29,12 @@
 
 # Completed Steps
 
+- the `head`, `tail` and `content` columns are BLOBs, each holding the raw 32
+  bytes of a SHA-256, half the size of the hex text they held. The hashes stay
+  raw from the hash phase through the database to `report` and `trees`. Reading
+  a record whose hash is not 32 bytes is an error (2026-10-26,
+  https://git.eeqj.de/sneak/sfdupes/issues/134)
+
 - the hash phase gives every file the walk records three hashes: `head` and
   `tail`, the SHA-256 of its first and last 64 KiB, and `content`, the SHA-256
   of the whole file under 100 MiB and of 1 MiB at each gigabyte from 100 MiB up.