Report a prune count that could not be read as unknown, not 0 (closes #96)

Prune read table row counts before and after to report how many orphaned files, chunks and blobs it removed, and discarded the error from every read. A failed query therefore reported as a count of 0, and the summary showed plausible wrong numbers.

A count that cannot be read is now logged as a warning (on stderr, also under --json) and shown as "unknown"; a difference computed from an unknown count is itself unknown. 0 still means the table was empty. No --json document carries these counts, so none can show a false 0.

model: claude-opus-4-8 (implementation, review); claude-fable-5-1 (merge)

TODO.md

@@ -25,6 +25,16 @@ release" is exactly the contradiction
 
 # Completed Steps
 
+- 2026-09-21: Stopped `prune` from reporting a failed row count as 0
+  ([issue #96](https://git.eeqj.de/sneak/vaultik/issues/96)). The seven
+  `getTableCount` reads in `PruneDatabase` discarded their error, so a
+  query that could not run became a plausible `0` and the before/after
+  delta computed from it looked like real work. Each read now logs at
+  warn on failure and renders as `unknown`, never `0`, so an empty table
+  is distinguishable from one that could not be queried. The counts have
+  no `--json` representation — under `--json` the summary is suppressed
+  entirely — so nothing there can show a false `0`.
+
 - 2026-09-21: Made the s3 storage backend report a missing object as
   `storage.ErrNotFound`, like the `file` and `rclone` backends and as the
   `Storer` interface documents. `S3Storer.Get` and `Stat` returned the raw
@@ -33,7 +43,6 @@ release" is exactly the contradiction
   helper (reused by `HeadObject`) and a test that a missing key maps to
   `ErrNotFound`
   ([issue #129](https://git.eeqj.de/sneak/vaultik/issues/129)).
-
 - 2026-09-21: Fixed `verify --deep` reporting healthy snapshots as
   corrupt. Its final blob-integrity check hashed the encrypted
   downloaded bytes with a single SHA256 and compared that to the blob