Phase 1 / D5: source maps for .twasm source-level debugging

[hyperpolymath]

Deliverable 5 of #49. Emit source maps so debuggers step .twasm source, not wasm bytes.

Scope

• Map emitted instruction byte-offsets → .twasm source spans.
• Choose the format: DWARF-in-wasm vs. the wasm sourcemap custom section (sourceMappingURL). Record the choice (ADR if it becomes load-bearing).
• Note: DWARF emission is also the seed of Phase 4 debugger integration (Phase 4: Tooling + developer experience #52) — pick a format that doesn't paint that into a corner.

Acceptance

• A debugger (or wasm-tools / browser devtools) shows .twasm line/column for examples/01-single-module.twasm.
• The map is validated against the emitted offsets in a test.

Dependencies

• Blocked by F (codegen v0). Extends per-example with D1.

Deliverable: Phase 1 / deliverable 5 (docs/PRODUCTION-PATH.adoc §Phase 1). Part of #49.

[hyperpolymath]

First increment landed in #141 (merged a66b13a): the producer now emits the wasm name section (function symbols), so debuggers and stack traces show real function names instead of indices. Tested in crates/typed-wasm-codegen/tests/names.rs.

Remaining for this issue: the full offset → source-line source map (DWARF-in-wasm or the wasm sourcemap custom section). That is gated on:

1. Source spans — only available once the front-end → IR seam (Phase 1 / D1: codegen coverage — all 10 levels across all 6 .twasm examples #127) carries .twasm line/column into the IR (today the IR is hand-built without spans), and
2. Accurate per-instruction byte offsets in the emitted body (wasm-encoder doesn't currently expose these).

---

Generated by Claude Code