Leave remote info orphan figures unknown when a manifest is unreadable (closes #228)

When a manifest could not be read, remote info skipped it, counted that
snapshot's blobs as orphaned and advised running prune. The orphan
figures are now unknown in that case, with no prune advice; --json gives
them as null and lists the unreadable remote keys in
unreadable_manifests. Only a listed manifest.json.zst is read, so a
directory without one, as an interrupted backup leaves, keeps the
figures known.

Names under metadata/ were used unchecked and printed raw. A name that
is not a remote key is now skipped with a warning. A manifest under it
is not read either, so it also leaves the figures unknown; --json counts
such manifests in skipped_manifests.

The closing log line carries the unreadable manifest count in place of
the orphan count.

Model: opus-5-5

TODO.md

@@ -22,6 +22,22 @@ the tag exists and is exercised; what is left is merging `next` to
 
 # Completed Steps
 
+- 2026-10-07: Made `remote info` stop reporting a snapshot's blobs as
+  orphaned when its manifest cannot be read, and stop printing raw
+  names from under `metadata/`
+  ([issue #228](https://git.eeqj.de/sneak/vaultik/issues/228)). A
+  manifest it failed to read was skipped, so that snapshot's blobs were
+  counted as orphaned and the report advised running `vaultik prune`.
+  The orphan figures are now unknown in that case, with no prune
+  advice, and `--json` gives them as `null` with the unreadable remote
+  keys in `unreadable_manifests`. A name under `metadata/` that is not
+  64 lowercase hex characters is now skipped with a warning instead of
+  being printed, control characters included. A manifest under a
+  skipped name is then not read either, so it also leaves the orphan
+  figures unknown, and `--json` counts such manifests in
+  `skipped_manifests`. A directory with no manifest in it, as left by an
+  interrupted backup, leaves the figures known.
+
 - 2026-10-07: Made a backup notice a file rewritten with its size
   unchanged and a new mtime in the same second as the one in the index
   ([issue #226](https://git.eeqj.de/sneak/vaultik/issues/226)). The