Collect transient native-emitter garbage on heap growth

[oxura]

Fixes the default-GC emission pressure reported in #1262. This addresses suggestion 1 (collect transient emission garbage), not the independent incremental-emission design in open #1386. I rechecked open PRs referencing #1262 before submitting; #1386 is the only existing one.

Change

Sample Bun heap use every 64 emitted definitions. Once it exceeds 2 GiB, collect; set the next checkpoint to the post-collection live heap plus 2 GiB. This avoids using physical host RAM as the transient-garbage budget and avoids repeatedly collecting large live books that cannot be reclaimed. No re-exec, global JSC environment override, scheduling rewrite, or per-definition full GC.

The guarded checkpoint leaves non-Bun compilation unchanged. README states the resource policy and explicitly says live state is not capped. No GUIDE or CHANGELOG edit; no protected checker/kernel/gate/allow-list/cap changes.

Actual before/after

Same public Chromi Eco entry, same dependency revisions and Linux x64 host (31 GiB RAM), same Bun executable. BUN_JSC_forceRAMSize was unset. The unchanged source compiler is main 2343aec; the treatment differs only by this checkpoint and its documentation.

Executed compiler	Peak RSS (KiB)	Wall time (s)	Status
Source, before	4483420	27.35	0
Source, after	3026800	26.58	0
Genuine installed-layout compiled CLI, after	3059936	26.60	0

All three generated C files are byte-identical, checked with cmp; SHA-256: 1170f0ac04a8116080efadd8394bc896eaf5cc05a6f373ad2bbbaa2be4ba0f34.

Repository shape/cap gate: 54/54. No nondeterministic memory assertion added to the permanent test suite.

Limits: the issue's private 27k-line Darwin application was unavailable; this is a real public large application, not a reproduction claim for that exact input. No Darwin/GPU run. This is a heap-growth collection policy, not a hard RSS limit and not a solution to intrinsically oversized live compiler state.

[nicolas-abril]

Unsupervised AI review (Claude, run by @nicolas-abril). Nobody has read this by hand yet, so please double-check it.

I pushed a commit on top of this PR with the same policy in fewer tokens:

• I dropped the emitted & 63 counter, so the heap is now sampled at every def. In Bun, process.memoryUsage() takes about 0.6 µs, so even 1,800 defs over a few passes cost only a few milliseconds.
• typeof Bun !== "undefined" && … Bun.gc(true) became globalThis.Bun?.gc(true).
• This saves 20 tokens. Merged onto current main (d71f42e), comp.ts goes from 64,014 (14 over the cap) to 63,994 (under it).

Checks on macOS: gates/repo.ts 54/54 and gates/test.ts 1600/1600. The C emitted for all 17 runtime benches is byte-identical to this PR's head. Compiling raytrace takes 105.7 ± 2.5 ms (PR) vs 105.3 ± 2.8 ms (this commit). I couldn't rerun the Chromi Eco measurement because I don't have it set up here. The collection policy itself didn't change.

I also didn't look further into what makes the emitter produce so much garbage. That would be the fix at the root.