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

A machine 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, but restore and verify accepted only the human ID, so recovery could not be done as documented.

Restore and verify now also accept a remote key, or an unambiguous leading part of it as snapshot list prints it, resolved against the store's metadata listing. Human IDs are never pure hex, which tells the two forms apart. Deep verify reads the single snapshot in the downloaded per-snapshot database. A new README section walks the recovery end to end; a test backs up, then lists, restores and deep-verifies with an empty index, another hostname and no age_recipients.

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

internal/vaultik/snapshot.go

@@ -670,9 +670,11 @@ func (v *Vaultik) VerifySnapshotWithOptions(
 
 	v.printVerifyHeader(snapshotID, opts)
 
-	// Download and parse manifest. The caller supplies a human
-	// snapshot ID; we hash it to address remote storage.
-	manifest, err := v.downloadManifestByKey(snapshot.RemoteSnapshotKey(snapshotID))
+	// Resolve the identifier to the snapshot's remote key and download the
+	// manifest. A human ID is hashed; a remote key (or its abbreviation,
+	// as printed for a remote-only snapshot) is used as-is, so a host with
+	// no local index can verify a snapshot it can only see on the store.
+	manifest, err := v.resolveAndDownloadManifest(snapshotID)
 	if err != nil {
 		if opts.JSON {
 			result.Status = verifyStatusFailed