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/repo-adapter.md

@@ -1,6 +1,6 @@
 ---
-status: draft
-last_updated: 2026-05-22
+status: stable
+last_updated: 2026-05-23
 ---
 
 # Repo Adapter: from-dbtype for @alkdev/operations
@@ -137,16 +137,17 @@ Overrides replace the auto-generated handler but keep the auto-generated `Operat
 - **Phase 2 concern** — this adapter is not part of phase 1. Phase 1 delivers the schema, module, and hosts.
 - **The adapter depends on both the element tree and the rendered Drizzle objects** — it needs the tree for schema derivation and the rendered tables for query execution
 - **Filter operators are column-type-dependent** — a `uuid` column gets different operators than a `boolean` column
-- **The `with` parameter for relations requires the Drizzle `relations` object** — the host must also render relations, not just tables
-- **Returning clauses are dialect-specific** — PG supports `.returning()` on all mutations, MySQL does not. The adapter must handle this per-dialect.
+- **The `with` parameter for relations requires the Drizzle `relations` object** — the adapter generates relations from module entries and rendered table objects (ADR-013)
+- **Returning clauses use graceful fallback** — all mutations call `.returning()`. The adapter checks the dialect string from the host config (`root.ctx.dialect`) to determine whether to include `.returning()`. Dialects that support it (PG, SQLite) return full result rows. Dialects that don't (MySQL) fall back to validated input (inserts) or affected row count (updates/deletes). This keeps the operations API uniform. See [ADR-012](decisions/012-always-returning-graceful-fallback.md).
+- **Relations are generated by the adapter, not the host** — the adapter reads `FooRelations` entries from the module and generates Drizzle `relations()` calls using the rendered table objects. No `<relation>` element type is needed. See [ADR-013](decisions/013-relation-rendering-adapter.md).
 
 ## Open Questions
 
-1. **Per-dialect handler differences?** PG has `.returning()` on all mutations, MySQL often doesn't. Should the adapter handle this transparently, or expose it in the config?
+1. ~~**Per-dialect handler differences?**~~ **Resolved — ADR-012**. Always use `.returning()` with graceful fallback. Dialects that support it return data; dialects that don't fall back to validated input or affected row count.
 
-2. **Schema bundle or separate schemas?** Should the adapter accept the `Type.Module` compiled bundle, or individual schemas? The module is convenient (everything in one place) but couples the adapter to TypeBox's module format.
+2. **Schema bundle or separate schemas?** Should the adapter accept the `Type.Module` compiled bundle, or individual schemas? The module is convenient (everything in one place) but couples the adapter to TypeBox's module format. (See [OQ-12](open-questions.md))
 
-3. **Relation rendering responsibility?** Should the host render relations (new `<relation>` element), or should the adapter generate them from the module's relation entries?
+3. ~~**Relation rendering responsibility?**~~ **Resolved — ADR-013**. The adapter generates relations from module entries and rendered table objects. No new `<relation>` element type is needed.
 
 ## References