Bind the local index to its backup destination

The local index tracks which chunks and blobs already exist at the
backup destination. Nothing was recording *which* destination, so
changing storage_url and running a backup left the scanner treating
every already-seen chunk as still-present at the new (empty) location.
Uploads were skipped silently and the resulting snapshots pointed at
blobs that don't exist at the new destination.

Fix: record storage_url in a new local_meta key-value table on first
mutating command, and refuse to proceed when the configured URL later
differs from the stored one. The error explains the two recovery
paths (revert the config, or run 'vaultik database purge' to discard
the index and rebuild from a fresh full backup).

Wired into snapshot create / prune / snapshot remove / snapshot purge
/ snapshot cleanup. Read-only inspection commands (snapshot list,
remote info, store info) are exempt.

internal/database/schema/001.sql

@@ -133,3 +133,17 @@ CREATE TABLE IF NOT EXISTS uploads (
 
 -- Index for efficient snapshot lookups
 CREATE INDEX IF NOT EXISTS idx_uploads_snapshot_id ON uploads(snapshot_id);
+
+-- Local metadata: keyed, host-local settings that bind the state of the
+-- local index database to external context. The primary use is
+-- storage_url: once a backup writes blobs to a destination, the local
+-- index is only valid against that destination — if the configured
+-- storage_url later changes, the scanner would silently think already-
+-- known chunks are still on the new (empty) destination and skip
+-- uploading them, corrupting future snapshots. On every mutating
+-- command startup, we compare the configured storage_url to the stored
+-- one and refuse to proceed on mismatch.
+CREATE TABLE IF NOT EXISTS local_meta (
+    key TEXT PRIMARY KEY,
+    value TEXT NOT NULL
+);