Count a file a backup could not store as failed (closes #280)

A file that phase 1 of a backup counted and phase 2 could not open,
because it was unreadable under --skip-errors or removed in between,
was added to the unchanged count while its size stayed in
BytesScanned. The summary showed it as unchanged with its bytes backed
up, and the snapshots row's file_count and total_size included it.

The scanner now counts such a file in FilesFailed and takes its size
out of BytesScanned. The summary's files line adds "N failed", and
file_count leaves the file out.

A directory phase 2 cannot record is not counted as failed, since
phase 1 counts no directories; that case has no test.

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-08: Counted a file that a backup could not store as failed
+  ([issue #280](https://git.eeqj.de/sneak/vaultik/issues/280)). A file
+  that phase 1 counted and phase 2 could not open, because it was
+  unreadable under `--skip-errors` or removed in between, was reported
+  in the summary as unchanged with its bytes as backed up, and the
+  `snapshots` row's `file_count` and `total_size` included it. The
+  summary now counts it as failed, and its data total and the row leave
+  it out.
+
 - 2026-10-08: Made `remote info` report a snapshot's blob count and
   blob size as unknown when its manifest cannot be read
   ([issue #272](https://git.eeqj.de/sneak/vaultik/issues/272)). The