docs: resolve architecture open questions, add type definitions, consolidate docs

Architecture review session resolving all high-priority open questions and
filling documentation gaps identified during review:

Decisions resolved:
- OQ-04: Flat props with inner escape hatch for column validation (ADR-007)
- OQ-05: PG enum pre-declaration returns enums and tables (ADR-008)
- OQ-06: Render results accumulate in root.ctx (resolved in hosts.md)
- Column references vs fk: references is shorthand, explicit fk takes
  precedence (ADR-006)
- ADR-001, 002, 003 promoted from Proposed to Accepted (probe-validated)

Documentation improvements:
- Complete DbColumnType mapping tables for all 14 types across 3 dialects
- Define ColumnMeta, TableMeta, IndexMeta, FkMeta types in elements.md
- Document inner prop, mode prop, and default prop semantics
- Add PgRootCtx, SqliteRootCtx, MySqlRootCtx context types
- Consolidate schema.md and module.md (remove duplication)
- Add end-to-end pipeline walkthrough to README
- Add glossary with 13 terms
- Add error handling strategy
- Remove duplicate content from hosts.md (cross-ref elements.md)

docs/architecture/open-questions.md

@@ -1,6 +1,6 @@
 ---
 status: draft
-last_updated: 2026-05-22
+last_updated: 2026-05-23
 ---
 
 # Open Questions Tracker
@@ -37,24 +37,26 @@ All unresolved architectural questions for dbtype, organized by theme.
 ### OQ-04: Should column elements support nested TypeBox schemas?
 
 - **Origin**: [elements.md](elements.md)
-- **Status**: Open
-- **Priority**: High
-- **Context**: The research docs proposed `DbType.String({ notNull: true, inner: Type.String({ format: 'email', maxLength: 255 }) })`. With UJSX elements, this would be `<column name="email" type="string" notNull format="email" maxLength={255} />`. The flat props model works for common cases, but custom validation constraints (patterns, ranges, custom checks) may need a nested `inner` prop. Should we support `<column name="email" type="string" notNull inner={Type.String({ format: 'email', maxLength: 255 })} />`?
-- **Cross-references**: ADR-001
+- **Status**: Resolved
+- **Priority**: ~~High~~ Resolved
+- **Context**: The research docs proposed `DbType.String({ notNull: true, inner: Type.String({ format: 'email', maxLength: 255 }) })`. With UJSX elements, this would be `<column name="email" type="string" notNull format="email" maxLength={255} />`. The flat props model works for common cases, but custom validation constraints (patterns, ranges, custom checks) may need a nested `inner` prop.
+- **Resolution**: Yes — flat props for common cases, `inner` as escape hatch for custom validation. When `inner` is provided, `extractTable()` uses it directly instead of calling `colToTypeBox()`. The host ignores `inner` — it's purely for the TypeBox schema. See [ADR-007](decisions/007-inner-escape-hatch.md).
 
 ### OQ-05: How to handle PG enum pre-declaration?
 
 - **Origin**: [hosts.md](hosts.md)
-- **Status**: Open
-- **Priority**: High
-- **Context**: PG requires `pgEnum()` at module scope before tables that reference it. Options: (A) return both enums and tables from render, (B) start with text for all enums, (C) per-column opt-in with `postgres: { nativeEnum: true }`. Option A is cleanest but changes the render API. Option B is simplest but loses PG enum validation.
+- **Status**: Resolved
+- **Priority**: ~~High~~ Resolved
+- **Context**: PG requires `pgEnum()` at module scope before tables that reference it. Options: (A) return both enums and tables from render, (B) start with text for all enums, (C) per-column opt-in with `postgres: { nativeEnum: true }`.
+- **Resolution**: Option A — the PG host accumulates enums in `ctx.enums` during the render walk. The consumer includes both `ctx.enums` and `ctx.tables` in their Drizzle schema. Enum names follow the `table_column` convention. See [ADR-008](decisions/008-pg-enum-predeclaration.md).
 
 ### OQ-06: Should hosts return rendered tables or store them in context?
 
 - **Origin**: [hosts.md](hosts.md)
-- **Status**: Open
+- **Status**: Resolved
 - **Priority**: Medium
 - **Context**: The probe scripts use `ctx.tables` to collect rendered tables. A more functional approach would have `render()` return the rendered table directly. Need to resolve this before implementation.
+- **Resolution**: render() accumulates results in root.ctx (tables, enums). The context shape varies by dialect — SQLite has ctx.tables, PG has ctx.tables and ctx.enums. See hosts.md Rendering Pipeline.
 
 ### OQ-07: Should we support JSX file extensions?
 
@@ -95,9 +97,9 @@ All unresolved architectural questions for dbtype, organized by theme.
 | OQ-01 | Relation naming convention | schema.md | Medium | Open |
 | OQ-02 | Derived schemas in module or separate | schema.md | Low | Open |
 | OQ-03 | Multiple database namespaces | schema.md | Low | Open |
-| OQ-04 | Nested TypeBox schemas in column props | elements.md | High | Open |
-| OQ-05 | PG enum pre-declaration | hosts.md | High | Open |
-| OQ-06 | Host render return value vs context | hosts.md | Medium | Open |
+| OQ-04 | Nested TypeBox schemas in column props | elements.md | ~~High~~ Resolved | **Resolved** — ADR-007 |
+| OQ-05 | PG enum pre-declaration | hosts.md | ~~High~~ Resolved | **Resolved** — ADR-008 |
+| OQ-06 | Host render return value vs context | hosts.md | Medium | Resolved |
 | OQ-07 | JSX file extensions | elements.md | Low | Open |
 | OQ-08 | Per-dialect handler differences | repo-adapter.md | Medium | Open |
 | OQ-09 | Relation rendering responsibility | repo-adapter.md | Medium | Open |