Compute the content hash only when head and tail match (closes #61)

A file of 10 MiB or more now gets only its 64 KiB head and tail in the
hash phase, so its content is read only when it can be a duplicate. A
new content phase after the update phase finds every group of records,
anywhere in the database, that share size, head and tail and include
one without a content hash. It checks every member with lstat and, when
at least two pass, reads those without a content hash through the
existing worker pool; a stale file does not count as a match. report
and trees leave out records without a content hash. The README, help
text and TODO entry describe the gate; the schema stays at version 1.

Lint suppressed: gosec on the file open in hashContentOnly, as in
hashSignature, and on one chmod in a test.

Model: opus-5-5

TODO.md

@@ -34,11 +34,16 @@
   https://git.eeqj.de/sneak/sfdupes/issues/61): a file under 10 MiB is
   hashed in full and compared directly, with no end-window step — its
   `head`, `tail`, and `content` all hold the whole-file hash. A file at
-  10 MiB or above is gated on the 64 KiB `head` and `tail`, then
-  compared on a `content` hash — the whole file below 50 MiB,
-  gigabyte-spaced 1 MiB samples at or above. The `content` column is
-  part of the version 1 schema. `report` and `trees` group by the
-  extended signature, so the ladder is applied across the whole
+  10 MiB or above gets only the 64 KiB `head` and `tail` in the hash
+  phase; a new content phase, after the update phase, reads it for its
+  `content` hash — the whole file below 50 MiB, gigabyte-spaced 1 MiB
+  samples at or above — only when its size, `head`, and `tail` match
+  another record's, from the same scan or stored by an earlier one, so
+  a stored file gains its content hash when it gains a match. A file
+  that is gone or has changed since its record was written is not
+  read. The `content` column is part of the version 1 schema. `report`
+  and `trees` group by the extended signature and leave out any record
+  without a `content` hash, so the ladder is applied across the whole
   database. README "Duplicate detection" documents every rung including
   the probabilistic large-file path.