docs: resolve all open architecture questions with ADRs 009-014

Resolve OQ-01 through OQ-10 with formal ADRs and update all architecture
docs to reference decisions. Add two new tracked questions (OQ-11, OQ-12)
surfaced during review.

ADR-009: Keep FooRelations naming convention for relation entries
ADR-010: One module per database, include derived schemas by default
ADR-011: Support JSX/TSX as ergonomic authoring layer
ADR-012: Always .returning() with graceful fallback per dialect
ADR-013: Adapter generates relations from module entries (no <relation> element)
ADR-014: Leverage drizzle-kit for migrations, no native migration generator

Also upgrades elements.md, hosts.md, repo-adapter.md status to stable,
clarifies OQ-06 as design clarification, and specifies MySQL .returning()
detection mechanism in ADR-012.

docs/architecture/module.md

@@ -137,6 +137,8 @@ Edits use JSON Pointer paths. A migration generator can translate these to:
 
 This is structural diffing, not semantic — it doesn't understand that changing `Type.String()` to `Type.String({ maxLength: 255 })` is a constraint addition, not a type change. Semantic diffing is a future concern.
 
+**Migration generation**: Leverage `drizzle-kit` for migrations. Since dbtype's primary output is Drizzle table definitions, `drizzle-kit generate` handles migration generation from those tables. The module's `Value.Diff` capability remains available as a foundation for future migration tooling, but is not used for production migrations in phase 1 or the foreseeable future. See [ADR-014](decisions/014-leverage-drizzle-kit-for-migrations.md).
+
 ## Cross-Module References
 
 `Module.Import()` embeds the source module's `$defs` in the resulting `TImport` schema. This enables referencing types from another module: