filelock: add replace_content for in-place locked rewrite

Rotation rewrites the database file while holding the exclusive lock;
flock follows the open file description across ftruncate, and on Windows
in-place rewrite avoids share-mode rename restrictions. Also update
rotation doc timestamp format to ISO basic with microseconds.

docs/rotation.md

@@ -44,13 +44,15 @@ The history that aged out is preserved at:
 - The timestamp is the **ts of the last record dropped by the rotation** (see
   step 4 — the leading snapshot of the rewritten main file carries the same
   ts), not the current time. The name tells you exactly which point in history
-  the rotated file ends at. Use a filesystem-safe rendering (e.g.
-  `2026-09-02T15-24-57` — no `:` characters, which are awkward on some
-  filesystems).
+  the rotated file ends at. Rendered in ISO 8601 basic format with the same
+  microsecond precision as the record's ``ts`` in the database (e.g.
+  `20260902T143000.123456Z`), so the filename matches precisely the ``ts`` of
+  the final line of the rotated file and of the snapshot at the start of the
+  new file.
 - The rotated name always ends in `.kantadb`, regardless of the original
   extension. Users may name their databases with no extension, `.kantadb`, or
   anything else (`.db`, …). Since the rotated name is derived from the *stem*,
-  all of these work uniformly: `data` → `data@2026-09-02T15-24-57.kantadb`,
+  all of these work uniformly: `data` → `data@20260902T143000.123456Z.kantadb`,
   `data.kantadb` → `data@….kantadb`, `data.db` → `data@….kantadb`.
 - Rotated files live in the same directory.
 - Collision: if a rotated file with the same name already exists (rotation