docs: add schema-evolution.md — TypeBox Value.Diff/Patch/Cast for schema evolution

docs/architecture/overview.md

@@ -281,11 +281,12 @@ storage node attributes and operations call events), they should either:
    application provides the key ring. This keeps the storage package agnostic to
    deployment-specific secret management.
 
-5. **Schema evolution strategy**: When graph type schemas evolve (new node types,
-    changed attribute schemas), who handles migration? The repository layer
-    should support schema version checking, but actual data migration scripts are
-    application-level. See [metagraph.md](./metagraph.md) for the versioning
-    approach.
+ 5. **Schema evolution strategy**: When graph type schemas evolve (new node types,
+    changed attribute schemas), how are changes detected and data migrated?
+    TypeBox's `Value.Diff` can diff schemas-as-JSON to detect changes,
+    `Value.Cast` can migrate data shapes, and `Value.Check` can verify
+    compatibility. The `version` field on `graph_types` tracks breaking changes.
+    See [schema-evolution.md](./schema-evolution.md) for the full design.
 
 6. **~~Should the repository layer live in `@alkdev/storage` or in a consumer
    package?~~** Decision: the repository CRUD layer (host-specific typed
@@ -301,6 +302,7 @@ storage node attributes and operations call events), they should either:
 ## References
 
 - Metagraph Module evolution: [metagraph-module.md](./metagraph-module.md)
+- Schema evolution via TypeBox value system: [schema-evolution.md](./schema-evolution.md)
 - Forward-looking connections: [forward-look.md](./forward-look.md)
 - Operations architecture: `/workspace/@alkdev/operations/docs/architecture/README.md`
 - Pubsub architecture: `/workspace/@alkdev/pubsub/docs/architecture/README.md`