Keep the local index when remote nuke cannot list or find the destination (closes #292)

`remote nuke` took a destination store it could not list, or one
without `vaultik-destination.txt` while the local index held
snapshots, as a warning: it then cleared the local snapshot records,
and for an unplugged volume's empty mount point reported the store
empty and exited zero. Nuke now fails on either before it removes
anything, without its advice to run it again, which would fail the
same way. The bulk remove it runs fails on either too; only a
local-only remove still goes on with a warning. Nuke also deletes each
snapshot's remote metadata before its local record, so a failed delete
keeps the snapshot in the local index rather than leaving it on the
store as a remote-only snapshot.

Model: opus-5-5

ARCHITECTURE.md

@@ -385,11 +385,12 @@ bucket/
 A destination without `vaultik-destination.txt` is treated as not present
 while the local index holds snapshots stored there (`checkDestinationMarker`
 in `internal/vaultik/destination_marker.go`): `snapshot create` refuses to
-write to it, `prune` and `snapshot purge` fail, and `snapshot list` and
-`snapshot remove` behave as for a destination that cannot be listed. This
-keeps those commands from taking an unplugged volume's empty mount point for
-a destination whose snapshots are all gone. The `file://` backend never
-creates its destination directory, so a write to a missing one fails.
+write to it, `prune`, `snapshot purge` and `remote nuke` fail, and
+`snapshot list` and `snapshot remove` behave as for a destination that cannot
+be listed. This keeps those commands from taking an unplugged volume's empty
+mount point for a destination whose snapshots are all gone. The `file://`
+backend never creates its destination directory, so a write to a missing one
+fails.
 
 The `{remote-key}` directory name is a one-way double SHA-256 hash of the human
 snapshot ID, so the human ID (hostname, snapshot name, timestamp) is never