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. The bulk remove nuke runs now fails on either
before it removes anything; only a local-only remove still goes on
with a warning. It also deletes each snapshot's remote metadata before
its local record, so a failed delete keeps the snapshot in the local
index under its name instead of leaving it on the destination 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