Say what the content phase's check does to a stale record

The README content phase item and the contentCandidates comment said a
file failing the check is not a duplicate. It keeps its record and does
not count as a match; with a content hash it is still reported until a
scan covering its tree updates or removes it.

Model: opus-5-5

README.md

@@ -339,11 +339,14 @@ during the hash phase:
     `content` hash, has its file checked with `lstat` first. A file
     that is gone, is no longer a regular file, or has changed (a
     different size, or an mtime newer than recorded) keeps its record
-    as it is and is not a duplicate. Any other `lstat` error is warned
-    about and counted as skipped, with the same result. The files that
-    pass and have no `content` hash are read only if at least two of
-    those records pass, so a file whose only matches are stale costs no
-    read; a file that already has a `content` hash is never read again.
+    as it is and does not count as a match for the others. Any other
+    `lstat` error is warned about and counted as skipped, with the same
+    result. If such a record has no `content` hash, it stays out of
+    duplicate groups; if it has one, it is still reported until a scan
+    covering its own tree updates or removes it. The files that pass
+    and have no `content` hash are read only if at least two of those
+    records pass, so a file whose only matches are stale costs no read;
+    a file that already has a `content` hash is never read again.
     They are read by a worker pool as in the hash phase, in inode order
     and once per inode, and their content hashes are committed in
     batches. A failed read is warned about and counted as skipped; its