Refuse a backup destination an unplugged volume left empty (closes #239)

Every backup writes vaultik-destination.txt at the destination root.
While the local index holds snapshots stored there, a destination
without it is not present: snapshot create refuses before writing,
prune and snapshot purge fail, and snapshot list and snapshot remove
act as for a destination that cannot be listed. snapshot create and
snapshot remove check it first. remote nuke deletes the marker last.
The file:// backend never creates its destination directory, which
protects a directory on a removable volume, not a mount point.

Tests back up into directories that exist; fixtures for a written
destination carry the marker.

Judgement call: the marker is rewritten on every backup.
Deviation: for the complexity limit, two blocks moved, unchanged, into
snapshotNamesToCreate and confirmRemoveSnapshot.

Model: opus-5-5

ARCHITECTURE.md

@@ -311,6 +311,8 @@ Repository interfaces:
 
 ```
 CreateSnapshot(opts)
+    │
+    ├─► markDestination()   // Refuse a destination without the marker, then write it
     │
     ├─► PruneDatabase()   // Critical: avoid dedup errors
     │
@@ -367,6 +369,8 @@ CreateSnapshot(opts)
 
 ```
 bucket/
+├── vaultik-destination.txt          # Marker written by every backup
+│
 ├── blobs/
 │   └── {hash[0:2]}/
 │       └── {hash[2:4]}/
@@ -378,6 +382,15 @@ bucket/
         └── manifest.json.zst        # Blob list (for pruning/verification)
 ```
 
+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.
+
 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
 written to the store as a directory name. See