nx_wasm_craft_vm_gate.nx

nx_wasm_craft_vm_gate.nx -- RUN THE SHIPPED CRAFT WASM, IN THE MEMORY THE BROWSER GIVES IT. WHY THIS EXISTS, stated plainly. On 2026-08-14 /craft shipped BROKEN TWICE while nx_wasm_craft_gate reported 59/59 GREEN both times, because that gate is NATIVE: it sys_mmaps CRAFT_TOTAL and therefore never meets the wasm memory bound at all. The WAT backend emits a FIXED 192 pages (12,582,912 bytes) without consulting the module's constants, so when the render ceiling was raised the arena outgrew it by 9.4 MB and every browser frame trapped with "index out of bounds". A page that traps paints NOTHING -- which is also how the characters disappeared, since mob_draw runs inside that render. ★THE LESSON THIS ORGAN ENCODES: A GATE THAT TESTS A DIFFERENT BUILD THAN THE ONE THAT SHIPS IS NOT TESTING THE PRODUCT. The native gate and the wasm are two builds of one source, and only one of them is what a visitor loads. This runs the ACTUAL .wasm the emitter produced, in a linear memory sized to exactly what the module declares, through the estate's own VM -- the same shape six sibling sims already use (nx_pendulum_wasm_vm_gate and friends) and which craft, the biggest of them, lacked. The two teeth are the two ways it broke, in the order it broke them: FITS -- the worst-case framebuffer (q=1, one ray per pixel) must lie inside the declared memory PAINTS -- after init+render the framebuffer must carry more than one colour PERF -- (2026-09-04) the long-frame door: perf_frame/perf_n/perf_long through the exports the page calls Neither can be satisfied by a trapping module, and PAINTS cannot be satisfied by a blank frame. license_tier: ORIGINAL expect_exit: 0