Hash a file again when its mtime moved back, not only forward (closes #176)

scan treated a recorded file as unchanged when its size matched and its
mtime was not newer. A file replaced by other content of the same size
with an older mtime, as cp -p, rsync -a or a restore writes it, kept the
hash of the file it replaced. Any mtime difference now counts as a
change. README.md says so, and a new test covers the older mtime.

Model: opus-5-5

README.md

@@ -208,8 +208,8 @@ makes the comparison exact. Reading samples cuts a 150 GiB file to about 150 MiB
 of reads, at the price of a comparison that is not exact.
 
 The hashes live in a database that is kept between runs. A rescan reads only new
-files, and files whose size changed or whose modification time (mtime) is newer
-than recorded. All analysis then works from the database alone.
+files, and files whose size or modification time (mtime) differs from their
+record. All analysis then works from the database alone.
 
 The goal is whole duplicated trees, not only single files. A download extracted
 twice, or a project copied once too often, is such a tree. It can be removed as
@@ -410,17 +410,16 @@ operands:
 
 - A file not yet in the database is hashed and inserted.
 - A file already in the database is not read again when its size and mtime match
-  its record. The mtime matches when it is not newer than the recorded one. This
-  is what makes a daily rescan cheap.
+  its record. This is what makes a daily rescan cheap.
 - When such a file's size on disk differs from its recorded `disk_size`, `scan`
   updates `disk_size` alone. It still does not read the file, and counts it as
   unchanged. ZFS, for example, counts a new file's blocks up to seconds after
   the write. A block is the unit in which a filesystem allocates disk space. A
   file scanned within those seconds gets its real `disk_size` at the next scan.
-- `scan` hashes a file again when its size differs or its mtime is newer. The
-  mtime is compared to the nanosecond, as finely as the filesystem records it. A
-  same-size rewrite counts as a change whenever the filesystem gives it a later
-  mtime, even within the same second.
+- `scan` hashes a file again when its size or its mtime differs from its record.
+  An older mtime counts as much as a newer one. A file put back by `cp -p`,
+  `rsync -a` or a restore from backup often has an older mtime. The mtime is
+  compared to the nanosecond, as finely as the filesystem records it.
 - The scan deletes each record under a scanned operand whose file it could not
   verify. That covers deleted files, and paths the scan could not stat or read
   this run. To stat a file is to read its details, such as its size, without