Add chunked offline render to bound WASM memory on long outputs

[olilarkin]

Problem

Stretching a short sound by a large factor (e.g. ~7 s × 482× → an hour-plus of audio) aborts the WebAssembly module with the generic "build with -sASSERTIONS for more info" message. This is an out-of-memory abort(), not a logic bug — reported downstream in paulstretch-for-live#2. It happens on the OfflineRenderer path (clicking Apply).

Root cause. renderMono/renderStereo build the entire output as one contiguous std::vector<float> in WASM linear memory, then to_js_float32_array allocates a second full-size copy — so peak memory is ≈ 2× the output, doubled again for stereo. The module links with -sALLOW_MEMORY_GROWTH=1 but no -sMAXIMUM_MEMORY, so the cap is Emscripten's 2 GiB default. A 7 s × 482× stereo render peaks well past that.

Fix

• Chunked offline render (the real fix). New OfflineRenderer::render_mono_chunked / render_stereo_chunked (C++) and renderMonoChunked / renderStereoChunked (WASM). Same DSP — the existing render loops are refactored into shared stream_channel / stream_stereo cores, so render_mono/render_stereo output is unchanged — but the result is delivered one bufsize() chunk at a time. Each chunk is copied out to a fresh JS-heap Float32Array, so peak WASM memory stays ≈ input + one chunk regardless of output length. The consumer accumulates chunks on the JS heap (or streams them to disk / an encoder).
• Memory cap bump. -sMAXIMUM_MEMORY=4294967296 (4 GiB wasm32 max) for immediate headroom. The chunked API is what removes the dependency on output length.
• TypeScript declarations + npm README section.

Tests

• tests/chunked_test.cpp (new):
  • Parity — chunked vs whole-buffer render match structurally (length, finiteness, peak, RMS; not bit-exact because the algorithm's per-instance PRNG seed differs per render, matching the streaming_test convention), every chunk is exactly bufsize, empty input is a no-op.
  • Memory limits — allocation-free check (via estimate_output_frames against named wasm32 caps) that a representative extreme render's buffered footprint overflows the 2 GiB default cap, and a bigger one overflows even the 4 GiB max, while the chunked working set stays ~16 KB.
• Extended the headless-Chrome browser smoke test (tests/browser/index.html) to exercise renderMonoChunked.

Verified locally

• ctest passes on PFFFT and ACCELERATE backends.
• WASM target builds; both new functions exported; built .wasm reports max 65536 pages (4 GiB).
• Browser smoke test passes under headless Chrome (data-status="ok").

Opening for CI before merge.