Decompose vera/codegen/api.py (2,228 lines): extract memory layout and execution runtime

[aallan]

Background

vera/codegen/api.py has grown to 2,228 lines and now mixes three distinct concerns: memory layout utilities, the public compile/execute API, and the host runtime setup. It follows the same growth pattern as codegen.py before it was split in #155.

Proposed split

vera/codegen/memory.py (~150 lines)

Extract the ADT memory layout utilities that are needed by both the compiler and the runtime:

• ConstructorLayout dataclass
• _wasm_type_size()
• _wasm_type_align()
• _align_up()

These are pure data/math utilities with no runtime dependency and are already imported by multiple codegen modules.

vera/codegen/runtime.py (~800 lines)

Extract the wasmtime execution layer:

• ExecuteResult dataclass
• _VeraExit exception
• execute() — sets up the wasmtime Store, linker, memory, all host imports (IO, Http, Inference, Map, Set, Regex, Markdown, …)
• All host_* functions (currently ~1,400 lines of the file)

Keep in vera/codegen/api.py (~300 lines)

• CompileResult dataclass
• compile() — the public compilation entry point

Acceptance criteria

• All 3,157 tests pass
• mypy vera/ clean
• Public API (from vera.codegen.api import compile, execute, CompileResult, ExecuteResult) unchanged
• api.py under 400 lines after the split

[aallan]

Scope supersession (June 2026 sweep): the file has doubled since this was filed — vera/codegen/api.py is now 4,253 lines, with execute() spanning lines 837–4253 (3,417 lines, 154 nested host closures). The June 2026 audit recommends extracting a vera/runtime/ package (one module per host-binding family) rather than the single runtime.py this body sketches, and the planning rework (PR #740) sequences two prerequisites first: the characterization harness (#734) and the GC bucket-as-truth migration (#706) — decomposing before #706 would churn the exact code it rewrites. Roadmap Tier 1. The acceptance criteria here otherwise stand: public API unchanged, api.py small after the split.