Reconcile the schema/migration docs with the code (closes #68)

Four documents implied vaultik has no schema-application mechanism and
told contributors to edit a nonexistent `schema.sql`. The code does have
numbered files in `internal/database/schema/` (`000.sql` creates the
`schema_migrations` table, `001.sql` the application tables) that
bootstrap a fresh database.

docs/DATAMODEL.md now owns the explanation, distinguishing the unchanged
policy (no upgrade path between versions; delete the local index and
re-back-up) from the bootstrap mechanism that does exist. README (caveat
and roadmap) and AGENTS.md are reworded to match and link there. AGENTS.md
now names the real file to edit and notes that the pre-1.0 disposability
clause expires on tagging.

Policy is unchanged; docs only.

model: claude-opus-4-8

AGENTS.md

@@ -104,7 +104,12 @@ Version: 2025-06-08
 
 13. Pre-1.0: NEVER write database migrations. There are no live databases
     anywhere — every user's local index can be rebuilt from a fresh full
-    backup. When the schema changes, just change `schema.sql` (and any code
-    that touches the affected tables). The local index is disposable until
-    1.0 ships and is tagged.
+    backup. To change the schema, edit `internal/database/schema/001.sql`
+    (and any code that touches the affected tables) directly; do not add new
+    numbered schema files. Those numbered files and the `schema_migrations`
+    table they populate only bootstrap a fresh database — they are not an
+    upgrade path. The local index is disposable until 1.0 ships and is
+    tagged; once 1.0 is tagged that clause expires and the question of
+    upgrading existing indexes returns. See [`docs/DATAMODEL.md`](docs/DATAMODEL.md)
+    for the full explanation.