BendRT paper: the CPU corpus size and the JS request path differ from comp.ts; a question about the CUDA cube #1822

Three passages in the BendRT paper (bend2/docs/BendRT/main.typ) disagree with bend2/comp.ts on main (de26a91). I'm filing this as an issue rather than a PR, since the papers are yours to word. Each item has a suggested sentence in case it helps.

1. The CPU corpus size (main.typ:297). The paper says the host "reserves 8 TB". corpus_setup maps 1ull << 33 (8 GiB) on the CPU (comp.ts:5405), and corpus_grow doubles it in place while it is under 1ull << 43 (comp.ts:5393). So 8 TiB is the cap, not the start. On macOS arm64 (at e5527d5), vmmap of a running binary showed one 8 GiB reservation, with 128 KiB resident.
Suggested: "the host maps 8 GiB at start and doubles it in place as the heap fills, up to 8 TiB, with pages faulting in on touch".

2. How a JS request reaches the loop (main.typ:528). The paper says a request "unwinds to the loop as a thrown value". The JS emitter returns { $: <name>, args: [...], kont: (x) => ... } (comp.ts:3236), and the loop continues with op = op.kont(x) (comp.ts:6552). At de26a91, tests/run/js_loop_capture.bend -o loop.js emits that object, and bun loop.js exits 0.
Suggested: "a request is returned to the loop as a tagged object carrying its continuation".

3. A question: the cube on CUDA (main.typ:114, 296, 407-411). The paper says the rings form "a 128 by 128 square, one ring per lane, the same on every target". On CUDA, gpu_probe sizes the cube from the L2 cache (comp.ts:5145): CUBE_LOG = 31 - CLZ(clamp(l2 >> 16, 16, 128)), and RING_LEN is 1 << (17 - CUBE_LOG) (comp.ts:3543). On an NVIDIA TITAN RTX (6 MiB L2, Linux, at e5527d5), the probe printed CUBE_LOG=6, so a 128 by 64 cube of 8192 rings with 2048 slots each. A Mac printed 128 by 128, with 16384 rings of 1024 slots. The total slot count is the same.
Which one is intended? If the code is right, the passage and its neighbours (":114 a fixed 128 by 128 grid", ":296 the 2^14 task rings", ":411 1024 slots") could say that the CUDA cube is sized from L2. If "the same on every target" is the design, then the probe is what changes.

The cited comp.ts lines and paper lines were re-read at de26a91. Items 1 and 3 were measured at e5527d5.

AI disclosure: a person asked for this check. Claude (an AI) compared the paper with the code, ran the macOS checks, and wrote this issue. Another Claude session ran the CUDA probe on the person's Linux machine. The person reviewed it and asked for it to be filed.