emit-c self-compile OOMs (>32 GiB): single ~12.9 GB allocation during `with --emit-c` on the compiler

[ehartford]

Summary

The --emit-c self-compile of the compiler exceeds the 32 GiB memory tripwire. During with build :test, right after EMIT-C SMOKE OK, the emit-c-test phase aborts with:

with: memory limit exceeded: committed=33819029136 requested=12884901904 limit=34359738368 bytes

i.e. committed = 33.8 GB, a single 12.9 GB allocation request, against the 32 GiB (34359738368) default cap. with build :test still exits 0 because the harness tolerates this late-phase abort, but it exceeds the tripwire and is a real resource bug.

Repro

# the emit-c-test phase runs, effectively:
./out/release/bin/with build out/gen/main.w --emit-c -o /tmp/main.c
# (or: with build :emit-c-test)

out/gen/main.w is the combined compiler source; this emits the whole compiler through the C backend.

Analysis / where to look

• The abort is a single 12.9 GB allocation (committed already 33.8 GB), i.e. one runaway Vec doubling (~6.4 GB → 12.9 GB) rather than diffuse accumulation. Look for an unbounded/duplicated buffer in the C backend (build/emit_c.w, the --emit-c codegen path), or a clone-style leak analogous to the comptime one below.
• This is the --emit-c cross-compilation path only (spec §16, --emit-c C source backend). The normal LLVM backend path is unaffected — check src/main.w is now 2.51 GB after the fix in the sibling change (comptime prepare_comptime_eval_copy was deep-cloning the full ~8.5 MB source text on every comptime eval). A similar per-something deep-copy in the emit-c path is a plausible cause.

Notes

• Pre-existing (documented previously as a cli-selfhost/high-RAM peak); not introduced by the comptime source-text fix (that only reduces memory).
• Spec reference: §16 (CLI reference), --emit-c (C source backend / cross-compilation).
• Target: memory for emitting the compiler should be well under 8 GB, not >32 GB.