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

Four documents told different stories about the database schema. docs/DATAMODEL.md now owns the explanation and separates two things: the policy, which is unchanged (no supported upgrade path between versions; delete the local index with vaultik database delete and back up again), and the schema bootstrap that does exist (numbered files in internal/database/schema applied to a fresh database and recorded in schema_migrations).

README.md and AGENTS.md are reworded to match and link there. AGENTS.md names the real file to edit, internal/database/schema/001.sql, and notes that the pre-1.0 disposability clause expires on tagging. No code changed.

Judgement call: REPO_POLICIES.md still names a different schema file; it is cross-project policy and was left alone.

model: claude-opus-4-8 (implementation, review); claude-fable-5-1 (merge)

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.