Store and compare file mtimes in nanoseconds (closes #226)

The files table held mtime in whole seconds and the scanner compared
whole seconds. A file rewritten with its size unchanged and a new mtime
in the same second as the indexed one was treated as unchanged, and
every later snapshot restored the old content. mtime is now stored as
nanoseconds since the Unix epoch and compared at that precision.

A local index written before this change holds seconds in mtime: its
next backup re-chunks every file once, and a restore of a snapshot made
before it sets mtimes near 1970.

An mtime outside the years 1678 to 2262 does not fit in int64
nanoseconds; it is stored wrong and restored wrong.

Model: opus-5-5

TODO.md

@@ -22,6 +22,16 @@ the tag exists and is exercised; what is left is merging `next` to
 
 # Completed Steps
 
+- 2026-10-07: Made a backup notice a file rewritten with its size
+  unchanged and a new mtime in the same second as the one in the index
+  ([issue #226](https://git.eeqj.de/sneak/vaultik/issues/226)). The
+  `files` table held mtime in whole seconds and the scanner compared
+  whole seconds, so every later snapshot kept the old content. `mtime`
+  now holds nanoseconds since the Unix epoch and is compared at that
+  precision. A local index written before the change holds seconds
+  there, so its next backup re-chunks every file once; chunks it already
+  stored are not uploaded again.
+
 - 2026-10-06: Made the backup summary and the `snapshots` row count each
   file, byte and upload once
   ([issue #225](https://git.eeqj.de/sneak/vaultik/issues/225)). The