Document that migrations are supported and none are added before 1.0 (closes #68)

The docs now say vaultik supports migrations. The numbered files in `internal/database/schema/` are migrations: `schema_migrations` records which have run, and opening a database applies any that have not. None are added before 1.0 because nothing is installed anywhere yet, so a schema change edits `001.sql` directly. After 1.0 each change is a new numbered file, and an existing local database is migrated when vaultik is updated.

`docs/DATAMODEL.md` owns the explanation. The README caveat and roadmap entry and `AGENTS.md` policy 13 link to it. This replaces the wording from #146, which said there was no upgrade path.

Disclosure: `CLAUDE.md` line 33, the owner's file, changes from "do not need to support migrations" to "do not add migrations before 1.0".

Model: opus-5-5

README.md

@@ -559,13 +559,13 @@ complete annotated example also lives in
   sequentially. Restore speed is bound by single-stream throughput.
 * **Device nodes, named pipes, and sockets are silently skipped.** Only
   regular files, directories, and symlinks are backed up.
-* **No upgrade path between versions.** There is no supported way to carry
-  an existing local index across a schema change; if the local SQLite
-  schema changes between versions, delete the local database (`vaultik
-  database delete`) and run a full backup. Remote storage is unaffected.
-  (The binary does embed numbered schema files and a `schema_migrations`
-  table to bootstrap a fresh database — see [`docs/DATAMODEL.md`](docs/DATAMODEL.md)
-  — but that is not an upgrade path.)
+* **Before 1.0, an update can make the local index unusable.** Vaultik
+  supports schema migrations, but none are added before 1.0 because
+  there is no installed base yet. If an update leaves your local index
+  unusable, run `vaultik database delete` and then a full backup; remote
+  storage is unaffected. After 1.0, the local index is migrated when
+  vaultik is updated. See
+  [`docs/DATAMODEL.md`](docs/DATAMODEL.md#schema-migrations).
 * **Files that change during backup may be inconsistent.** There is no
   filesystem snapshot or freeze. If a file is modified between the scan
   and chunk phases, the backed-up copy may reflect a partial write.
@@ -631,12 +631,11 @@ priority.
 
 ### infrastructure
 
-* **Cross-version schema upgrades.** There is no upgrade path between
-  released versions — pre-1.0 schema changes are handled by `vaultik
-  database delete` plus a full re-scan (see
-  [`docs/DATAMODEL.md`](docs/DATAMODEL.md)). Post-1.0 we'll need a
-  migration story to keep existing index databases usable across
-  upgrades.
+* **Schema migrations after 1.0.** Migrations are supported, but none
+  are added before 1.0 because there is no installed base yet. After
+  1.0, each schema change is a new migration, so an existing local
+  index is migrated when vaultik is updated (see
+  [`docs/DATAMODEL.md`](docs/DATAMODEL.md#schema-migrations)).
 * **Storage backend coverage tests.** S3, file://, and rclone://
   all share the Storer interface but the rclone path is the least
   exercised in CI.