Consolidate CLI verbs; retire overlapping commands

The verb surface accumulated overlapping cleanup commands. Consolidate
so each cleanup verb has one meaning:

- Rename 'database purge' -> 'database delete'. The command removes the
  SQLite file entirely; "purge" wrongly suggested purging contents.
- Fold 'snapshot cleanup' into 'prune'. Prune now runs three passes:
  reconcile local snapshots against the remote (previously the
  standalone cleanup command), drop orphaned local rows, then delete
  unreferenced remote blobs. One command, one mental model.
- Delete 'store info'. Its output was a strict subset of 'remote info',
  which already prints storage type + location. Any user reaching for
  either should reach for 'remote info'.
- Drop 'snapshot remove --all'. It duplicated 'remote nuke --force'.
  'remote nuke' is the single supported entry point for wiping the
  destination store.

Also update the storage-binding error message to reference the new
'vaultik database delete' name.

README.md

@@ -99,15 +99,13 @@ vaultik [--config <path>] snapshot create [snapshot-names...] [--cron] [--prune]
 vaultik [--config <path>] snapshot list [--json]
 vaultik [--config <path>] snapshot verify <snapshot-id> [--deep] [--json]
 vaultik [--config <path>] snapshot purge [--keep-latest | --older-than <duration>] [--snapshot <name>...] [--force]
-vaultik [--config <path>] snapshot remove <snapshot-id|--all> [--dry-run] [--force] [--local-only] [--json]
-vaultik [--config <path>] snapshot cleanup
+vaultik [--config <path>] snapshot remove <snapshot-id> [--dry-run] [--force] [--local-only] [--json]
 vaultik [--config <path>] snapshot restore <snapshot-id> <target-dir> [paths...] [--verify]
 vaultik [--config <path>] prune [--force] [--json]
 vaultik [--config <path>] info
 vaultik [--config <path>] remote info [--json]
 vaultik [--config <path>] remote nuke --force
-vaultik [--config <path>] store info
-vaultik [--config <path>] database purge [--force]
+vaultik [--config <path>] database delete [--force]
 vaultik completion <bash|zsh|fish|powershell>
 vaultik version
 ```
@@ -198,7 +196,7 @@ latest globally).
 * `--snapshot <name>`: Restrict to specific snapshot names (repeat for multiple)
 * `--force`: Skip confirmation prompt
 
-**`snapshot remove`**: Remove a snapshot. By default this removes the
+**`snapshot remove`**: Remove one snapshot. By default this removes the
 snapshot from the local index and strips the snapshot's metadata from
 the backup destination store. Blobs are NOT touched — deleting blobs
 requires reading every remaining remote manifest (the destination store
@@ -208,17 +206,13 @@ prune` invocation to run as a follow-up. Local row cleanup (files,
 chunks, blobs the snapshot was the last referrer for) runs
 automatically. If the destination store is unreachable, the local-DB
 removal still completes and a warning is emitted; rerun `vaultik prune`
-once the store is reachable to finish remote cleanup.
+once the store is reachable to finish remote cleanup. To wipe everything
+on the destination in one go, use `vaultik remote nuke --force`.
 * `--local-only`: Skip remote cleanup; only touch the local index
-* `--all`: Remove all snapshots (requires `--force`)
 * `--dry-run`: Show what would be deleted without deleting
 * `--force`: Skip confirmation prompt
 * `--json`: Output result as JSON
 
-**`snapshot cleanup`**: Remove stale local snapshot records that have no
-corresponding metadata in remote storage. These are typically left behind
-by incomplete or interrupted backups. Does not touch remote storage.
-
 **`snapshot restore`**: Restore files from a backup snapshot.
 * Requires `VAULTIK_AGE_SECRET_KEY` environment variable
 * Optional path arguments to restore specific files/directories (default: all)
@@ -226,31 +220,38 @@ by incomplete or interrupted backups. Does not touch remote storage.
   symlinks, and empty directories
 * `--verify`: After restoring, verify every file's chunk hashes match
 
-**`prune`**: Tidy up everything that isn't needed. Removes orphaned local
-database rows (files, chunks, blobs no longer referenced by any completed
-snapshot) AND deletes unreferenced blobs from remote storage. `snapshot
-create --prune`, `snapshot remove`, and `snapshot purge` run the same
-cleanup automatically; this is the manual entry point for the same work.
+**`prune`**: Tidy up everything that isn't needed. Runs three passes:
+(1) reconcile the local index against the destination store — any
+local snapshot whose remote metadata is missing is dropped from the
+local index; (2) delete orphaned local rows (files, chunks, blobs no
+longer referenced by any completed snapshot); (3) list every remote
+manifest on the destination store to compute the still-referenced blob
+set and delete any blob not in that set. Step (3) reads all remote
+manifests — network cost scales with the number of snapshots. `snapshot
+create --prune` runs the same cleanup automatically; this is the
+manual entry point for the same work.
 * `--force`: Skip confirmation prompt
 * `--json`: Output stats as JSON
 
 **`info`**: Display system configuration, storage settings, encryption
 recipients, and local database statistics.
 
-**`remote info`**: Show detailed remote storage information including per-snapshot
-metadata sizes, blob counts, and orphaned blob detection.
+**`remote info`**: Show storage backend type and location plus detailed
+remote storage inventory: per-snapshot metadata sizes, blob counts, and
+orphaned blob detection.
 * `--json`: Output as JSON
 
 **`remote nuke`**: Delete every snapshot's metadata and every blob from the
 backup destination store, leaving the bucket prefix empty. Destructive and
-irreversible.
+irreversible. This is the single supported way to wipe the entire
+destination store.
 * `--force`: Required to confirm destruction.
 
-**`store info`**: Display storage backend type and statistics.
-
-**`database purge`**: Delete the local SQLite state database entirely. Remote
-storage is unaffected; the next backup will do a full scan and re-deduplicate
-against existing remote blobs.
+**`database delete`**: Delete the local SQLite state database file
+entirely. Remote storage is unaffected; the next backup will do a full
+scan and re-deduplicate against existing remote blobs, and the local
+index will re-bind to the currently configured storage destination.
+Use this after changing `storage_url` to a different destination.
 * `--force`: Skip confirmation prompt
 
 ---
@@ -387,7 +388,7 @@ Key fields:
 * **Device nodes, named pipes, and sockets are silently skipped.** Only
   regular files, directories, and symlinks are backed up.
 * **No database migrations.** If the local SQLite schema changes between
-  versions, delete the local database (`vaultik database purge`) and run
+  versions, delete the local database (`vaultik database delete`) and run
   a full backup. Remote storage is unaffected.
 * **Files that change during backup may be inconsistent.** There is no
   filesystem snapshot or freeze. If a file is modified between the scan
@@ -459,7 +460,7 @@ priority.
   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 purge` plus a full
+  changes are handled by `vaultik database delete` plus a full
   re-scan. Post-1.0 we'll need a migration story to keep existing
   index databases usable across upgrades.
 * **Storage backend coverage tests.** S3, file://, and rclone://