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

#146 called the numbered schema
files a bootstrap and said vaultik has no upgrade path between versions.
That was wrong: they are migrations, and database.New applies any the
database has not recorded. None are added before 1.0 because nothing is
installed anywhere yet; after 1.0 each schema change is a new numbered
file and the local database is migrated on update.

docs/DATAMODEL.md gets a Schema Migrations section that owns the
explanation. The README caveat and roadmap entry and AGENTS.md policy 13
say the same and link to it. CLAUDE.md, the owner's file, gets a
one-line edit so it no longer says migrations are not needed.

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.