Store mtime in nanoseconds so a same-second rewrite is re-hashed (closes #12)

scan recorded mtime in whole seconds, so a file rewritten in place at
the same size within the same second as its recorded mtime was classed
unchanged and kept its old hashes. The walk, a file given as an operand,
and the content phase's recheck now all use ModTime().UnixNano(); the
change rule itself is unchanged. The column stays INTEGER and
PRAGMA user_version stays 1, per the owner's ruling. A database written
by an earlier build holds seconds, so its files count as changed once,
at the next scan that covers them. README states the new resolution.

Model: opus-5-5

README.md

@@ -314,7 +314,7 @@ All three subcommands operate on a single SQLite database file:
     CREATE TABLE files (
         path    BLOB PRIMARY KEY,  -- absolute path, raw bytes
         size    INTEGER NOT NULL,  -- bytes, from lstat
-        mtime   INTEGER NOT NULL,  -- Unix seconds, from lstat
+        mtime   INTEGER NOT NULL,  -- Unix nanoseconds, from lstat
         head    TEXT NOT NULL,     -- lowercase-hex SHA-256; first 64 KiB, or whole file under 10 MiB
         tail    TEXT NOT NULL,     -- lowercase-hex SHA-256; last 64 KiB, or whole file under 10 MiB
         content TEXT NOT NULL      -- lowercase-hex SHA-256, whole file or samples
@@ -421,6 +421,9 @@ operands:
   once its size, `head`, and `tail` match another record's.
 - A file whose mtime is newer than recorded, or whose size differs, is processed
   as if new: re-hashed, or recorded without hashes, per the shared-size rule.
+  The mtimes are compared in nanoseconds, as finely as the filesystem records
+  them, so a same-size rewrite later in the same second as the recorded mtime
+  still counts as a change.
 - A database record whose path lies under one of the scanned operands but was
   not successfully processed this run is deleted. This removes records for
   deleted files. It also removes records for paths that failed to stat or hash