Re-chunk a known file whose chunks no uploaded blob holds (closes #214)

File rows are shared by every snapshot and updated in place, while a
blob row is deleted once no snapshot references it. Removing the newest
snapshot, or the prune after an interrupted run, could drop the only
blob holding a changed file's current chunks while an older snapshot
kept the file row. The next backup compared metadata only, skipped the
file, and completed a snapshot that could not restore it.

The scanner now loads the IDs of known files that list a chunk no
uploaded blob holds and re-chunks them even when their metadata is
unchanged.

The tests append to a file, so the file keeps its first chunk in a blob
the first snapshot still references. Each backup run gets its own
snapshot name, so the second-precision snapshot IDs differ without
sleeping.

Model: opus-5-5

TODO.md

@@ -22,6 +22,15 @@ the tag exists and is exercised; what is left is merging `next` to
 
 # Completed Steps
 
+- 2026-10-06: Made a backup re-chunk a known file that lists a chunk no
+  uploaded blob holds
+  ([issue #214](https://git.eeqj.de/sneak/vaultik/issues/214)). File
+  rows are shared by every snapshot and updated in place, so removing or
+  pruning the only snapshot that referenced a changed file's current
+  blob left an older snapshot keeping a row that matched the disk while
+  no blob held its chunks. The next backup skipped the file and
+  completed a snapshot that could not restore it.
+
 - 2026-09-22: Routed the last direct-to-stdout command output through
   `internal/ui`
   ([issue #149](https://git.eeqj.de/sneak/vaultik/issues/149)). The