Make snapshot remove fail for an unknown snapshot ID (closes #293)

snapshot remove never checked that the ID existed: it deleted nothing,
reported the snapshot removed from the local database and from the
destination store, and exited 0, under --json, --dry-run and
--local-only too. It now looks the ID up in the local index and, only
when that has no row and --local-only is not set, on the destination
store; finding neither is an error. The command reports a removal from
the local database only when the local index had the row, and
remote_removed is true only when metadata was actually deleted.

Judgement call: under --local-only the destination store is not
consulted, so the snapshot must be in the local index.

Model: opus-5-5

README.md

@@ -349,9 +349,11 @@ the backup destination store. Blobs are NOT touched — deleting blobs
 requires reading every remaining remote manifest (the destination store
 may hold snapshots this host doesn't know about), which is what
 `vaultik prune` does. On success the command prints the exact `vaultik
-prune` invocation to run as a follow-up. Local row cleanup (files,
-chunks, blobs the snapshot was the last referrer for) runs
-automatically. If the destination store is unreachable, the local-DB
+prune` invocation to run as a follow-up. An ID that names no snapshot in
+the local index or on the destination store is an error; with
+`--local-only`, the snapshot must be in the local index. Local row
+cleanup (files, chunks, blobs the snapshot was the last referrer for)
+runs automatically. If the destination store is unreachable, the local-DB
 removal still completes and a warning is emitted; run `vaultik snapshot
 remove <snapshot-id>` again once the store is reachable to remove the
 snapshot's metadata from it (`vaultik prune` does not). To wipe everything