Accept a remote key for restore and verify, and document it (closes #124)

A host restoring after the original is gone has no local index and cannot
know a snapshot's human ID; `snapshot list` shows such snapshots only by
their remote key. Restore and verify now resolve an identifier to that
remote key: a human ID is hashed as before, and a remote key (or an
unambiguous leading part of it, as the table prints) is used directly,
resolved against the store's metadata listing. Deep verify reads the one
snapshot in the exported database rather than filtering by the human ID.

Adds an integration test that backs up with one index and hostname, then
lists, restores, and deep-verifies from the store with a fresh empty
index, a different hostname, and no age_recipients — comparing restored
bytes to the source. The empty index is what makes it fail if restore
ever needed the original one.

Adds a "Restoring on another machine" README section walking the flow end
to end, and drops the now-done roadmap item.

Model: claude-opus-4-8

README.md

@@ -84,6 +84,57 @@ VAULTIK_AGE_SECRET_KEY='AGE-SECRET-KEY-...' vaultik snapshot restore <snapshot-i
 # 0 3 * * * vaultik snapshot create --cron --prune --keep-newer-than 4w
 ```
 
+## restoring on another machine
+
+Restoring on a host that never ran the backup — a replacement machine
+after the original is gone — is the case vaultik is built for. That host
+needs only three things: the `vaultik` binary, the age **private** key,
+and the storage credentials for the destination. It does **not** need the
+local index, the original config file, or the original hostname.
+
+```sh
+# install
+go install sneak.berlin/go/vaultik/cmd/vaultik@latest
+
+# create a config and point it at the ORIGINAL backup destination
+vaultik config init
+vaultik config set storage_url "s3://bucket/prefix?endpoint=https://s3.example.com"
+vaultik config set s3.access_key_id "..."
+vaultik config set s3.secret_access_key "..."
+
+# see what is on the destination store
+vaultik snapshot list
+```
+
+`snapshot list` reads the destination store without the private key. A
+snapshot that is not in this host's (empty) local index is shown as
+remote-only: its row is identified by `<remote only:...>` rather than by
+a `hostname_name_timestamp` name, because the name lives only in the
+local index and the encrypted database and cannot be recovered from the
+store. Its timestamp and compressed size are real. (See the `snapshot
+list` description under [command details](#command-details) for the full
+explanation.)
+
+Use that remote key — the hex printed inside `<remote only:...>`, or the
+full `remote_key` from `snapshot list --json` — to restore and verify:
+
+```sh
+# restore everything to /tmp/restored, then check every restored file's
+# chunk hashes
+VAULTIK_AGE_SECRET_KEY='AGE-SECRET-KEY-...' \
+  vaultik snapshot restore --verify <remote-key> /tmp/restored
+
+# optionally, deep-verify the snapshot against the store (downloads and
+# cryptographically checks every blob)
+VAULTIK_AGE_SECRET_KEY='AGE-SECRET-KEY-...' \
+  vaultik snapshot verify --deep <remote-key>
+```
+
+`age_recipients` (the public key) is not needed to restore — only the
+private key in `VAULTIK_AGE_SECRET_KEY`. Both the abbreviated key printed
+in the table and the full 64-character key from `--json` are accepted; a
+leading part of the key is enough as long as it is unambiguous.
+
 ---
 
 ## cli
@@ -245,6 +296,8 @@ local index alone, and still exits zero.
 * Default (shallow): checks that all blobs referenced in the manifest exist in storage
 * `--deep`: Downloads and decrypts each blob, verifies chunk hashes against the
   encrypted metadata database
+* Accepts the same identifiers as `snapshot restore`: a snapshot ID, or a
+  remote-only snapshot's remote key (or an unambiguous leading part of it)
 * `--json`: Output results as JSON
 
 **`snapshot purge`**: Remove old snapshots based on criteria. Retention is
@@ -275,6 +328,10 @@ on the destination in one go, use `vaultik remote nuke --force`.
 
 **`snapshot restore`**: Restore files from a backup snapshot.
 * Requires `VAULTIK_AGE_SECRET_KEY` environment variable
+* Accepts a snapshot ID, or — for a snapshot only on the destination
+  store — its remote key (or an unambiguous leading part of it) as shown
+  by `snapshot list`. See
+  [restoring on another machine](#restoring-on-another-machine).
 * Optional path arguments to restore specific files/directories (default: all)
 * Preserves file permissions, timestamps, ownership (ownership requires root),
   symlinks, and empty directories
@@ -525,10 +582,6 @@ priority.
 
 ### infrastructure
 
-* **Cross-machine restore documentation.** The "restore from
-  another host" workflow works but isn't documented as a
-  first-class operation in this README. Worth a dedicated section
-  once it's settled.
 * **Schema migrations.** Currently nonexistent — pre-1.0 schema
   changes are handled by `vaultik database delete` plus a full
   re-scan. Post-1.0 we'll need a migration story to keep existing