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

PruneDatabase read seven table counts with the error discarded, so a
query that could not run silently became 0 and the before/after delta
computed from it looked like real work.

Each read now goes through a helper that logs at warn on failure and
returns nil; nil renders as "unknown", never "0", so an empty table is
distinguishable from one that could not be queried. Deltas built from an
unknown count are themselves unknown. The failure is surfaced, not
propagated, so the command's failure conditions are unchanged. These
counts have no --json output — under --json the summary is suppressed
entirely — so nothing there can show a false 0.

Model: opus-4-8

TODO.md

@@ -25,6 +25,15 @@ 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: 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