@woosh/meep-engine 3.28.0 → 3.30.0

package/src/shade/renderer/geometry/meshlet/COMPACTION_PLAN_2026_09_16.md

@@ -0,0 +1,663 @@
+# GPUMeshletManager — compaction under churn
+
+*2026-09-16. Revision 3: built. Revision 2 was the reviewed plan (§9); §8 has what each row
+measured and the commit that landed it, §10 what the build changed against the plan.*
+
+`GPUMeshletManager` is the shared meshlet pool: static meshes, skinned clones
+(`clone_batch_allocation`), dynamic meshes, the scene editor's asset swaps, and the virtual-geometry
+tier's pages all live in its two arenas. Virtual geometry is the motivator here — it is the first
+client to churn the pool at tens of allocations a second — but nothing below is shaped to it. A
+page is a batch like any other; the plan treats "many near-uniform batches coming and going around
+a few large ones that stay, with the occasional large one swapped" as the load, and that load is a
+skinned crowd's respawns or an editor's asset swaps as much as it is a page tier.
+
+The defect: `compact()` is a two-buffer rebuild that re-allocates and re-uploads *every* record and
+fires `changed` for every one that moved, O(all batches) in one event, and the allocation path
+calls it whenever a request is refused with enough free space behind it. On the Zorah container
+(4,096 page slots, ~60 KB pages, ~34 clusters each) a two-round tour of eight rosettes turned over
+3,009 pages, and the only main-thread tasks over 50 ms — four of them, 79 to 115 ms — were each a
+`compact()` (RUNTIME_PLAN_2026_09_14 §7). Everything else the residency does per reading is
+microseconds.
+
+## 0. Decision
+
+Four changes, landed and measured in two steps (§8):
+
+1. **Quantize allocations to the allocator's bins.** Every request is rounded up to
+   `allocator_run_size_for(size)` before it reaches the `OffsetAllocator`. A hole left by a freed
+   batch is then exactly a bin, and any request of the same class is accepted from it. This removes
+   the "fitting hole refused" class of refusal (63–80 % of refusals measured, §2.1) and most of the
+   splintering behind the rest, at 3.4 % of data words and 3.9 % of metadata rows on page-shaped
+   sizes (worst case 12.5 %, the allocator's own bin ratio).
+2. **A byte-level metadata patch** in place of the per-row struct serde, for `add_batch` and the
+   rebuild alike: the rows are packed at 40 bytes with `address` at word 6, so patching a batch is a
+   copy and one add per row. This is most of the 28 µs a record the rebuild costs today (§2.2), and
+   `add_batch` pays the same serde on every promotion.
+3. **Refusal policy: grow, never re-pack to zero headroom.** A refused request grows the arena
+   (which leaves 25 % headroom and moves nothing) and, when the refusal was fragmentation, arms the
+   sweep. At most one growth per sweep episode; a second fragmentation refusal before the sweep has
+   finished falls back to the rebuild, which is now bounded by step 2. The full rebuild stays
+   public as `compact()` and is the last resort when the device's buffer limit stops growth.
+4. **A sliding, budgeted compactor** for the fragmentation that quantization does not prevent —
+   mixed size classes, a large asset swapped under small churn: an O(1) `OffsetAllocator#slide_down`
+   primitive swaps a used range with the free range before it; the manager walks a cursor up each
+   arena and slides records down over the free space that gathers behind the cursor, at most
+   `MOVE_BUDGET` records and `WORD_BUDGET` words per `sweep(cmd_ctx)`, which the renderer calls once
+   per frame. A moved record's bytes — data *and* metadata rows — go through a transient staging
+   buffer (two `copyBufferToBuffer`, so an overlapping move is well-defined and GPU-written rows
+   survive); a data move also patches the rows' `address` with the address-patch shader the clone
+   flush already uses; `changed` fires. Per-frame cost is bounded by the budget, not by the
+   resident count.
+
+Steps 1–3 are landed first and measured (§8, C2/C4): under the motivating load they leave the sweep
+with nothing to do, and that is recorded rather than assumed. Step 4 is then built against a load
+that needs it (§2.4) and proved on that load.
+
+Everything a consumer has to do is in §5: `changed` keeps its meaning and gains a per-frame bound;
+`GPUGeometryManager` patches the one row a move touches instead of logging a warning;
+`GPUMeshSkinningContext` starts listening, which it never did.
+
+## 1. The manager today
+
+Two `OffsetAllocator`s, data (words) and metadata (rows), over two `GPUBuffer`s. A record holds an
+`Allocation` in each. `#allocate_data_and_metadata` tries both, and on refusal of either:
+
+- if `#deallocations_since_last_rebuild > 0` and the refused allocator's `freeStorage` is at least
+  `allocator_run_size_for(size)` — i.e. a rebuild *would* hand the request one run — it calls
+  `compact()`;
+- otherwise it calls `grow()`, which appends and moves nothing.
+
+`compact()` = `#rebuild`: new buffer pair, fresh allocators, every record re-allocated in insertion
+order, one `copyBufferToBuffer` per record for data, one CPU re-encode and `writeBuffer` per record
+for metadata (`#write_patched_metadata`, generic struct serde per row), `changed.send0()` for every
+record whose data offset changed. Node budget re-picked. The new arenas are the old *sizes*: a
+rebuild adds no space, it only packs — to whatever headroom the last growth left.
+
+Consumers of a record (§5): `GPUGeometryManager` writes `metadata.offset` into the geometry table
+and answers `changed` with a `console.warn` and a TODO; `GPUVirtualGeometryPool` writes it into a
+page row and follows `changed` correctly; `GPUMeshSkinningContext` caches both offsets in a binding
+and keys a per-meshlet table by absolute clone row, and does not listen. BLAS leaves carry
+batch-local meshlet indices and need nothing.
+
+## 2. Measurements (before touching anything)
+
+Node, `SoftwareGPUDevice`, synthetic churn: a resident set of `N` "page" batches drawn uniformly
+from 14,000–16,000 words and 30–38 rows (the Zorah shape: ~60 KB, ~34 clusters), plus six static
+batches of 33 K to 2.4 M words that stay for the whole run; then `2N` churn events, each evicting a
+uniformly random resident page and adding a fresh one. The driver is `churn_bench.mjs` in the
+session scratchpad; §6 checks the load-bearing numbers in as a bench spec. The real tier evicts in
+CLOCK order, which fragments *less* (62 raw refusals against 255 uniform at 12 % headroom, 4,096
+resident); uniform eviction is the conservative choice.
+
+The bare-allocator runs below are at a quarter of the real sizes and the manager runs had to be
+(the software device caps `maxBufferSize` at 256 MB and 4,096 real pages are 245 MB before
+headroom). The allocator's bins are a 3-bit float, so a quarter-scale page draws the same three
+bins one exponent lower (3,584 / 3,840 / 4,096 at 17 / 51 / 32 % against 14,336 / 15,360 / 16,384
+at 17 / 51 / 32 %); the real-scale refusal counts are within 20 % of the quarter-scale ones in
+every column and split the same way.
+
+### 2.1 Why near-uniform churn fragments an `OffsetAllocator` at all
+
+Bare allocator, arena = live × 1.12, refusal classified by the true hole structure computed from
+the live ranges:
+
+| resident | churn | requests | refused | of which a *fitting* hole was refused | of which true fragmentation | holes at end |
+|---:|---:|---|---:|---:|---:|---:|
+| 512 | 1,024 | raw | 15 | 12 | 3 | 253 |
+| 512 | 1,024 | quantized | 0 | 0 | 0 | 56 |
+| 1,024 | 2,048 | raw | 54 | 40 | 14 | 478 |
+| 1,024 | 2,048 | quantized | 0 | 0 | 0 | 109 |
+| 2,048 | 4,096 | raw | 139 | 96 | 43 | 959 |
+| 2,048 | 4,096 | quantized | 0 | 0 | 0 | 115 |
+| 4,096 | 8,192 | raw | 269 | 186 | 83 | 1,895 |
+| 4,096 | 8,192 | quantized | 0 | 0 | 0 | 194 |
+
+Two mechanisms, and both are the bins:
+
+- **A hole serves only the bin below its own.** A free run is filed under the largest bin that fits
+  *inside* it (`uintToFloatRoundDown`); a request is looked up from the smallest bin that fits the
+  *request* (`uintToFloatRoundUp`). Bins at 8,192–16,384 words are 1,024 apart, so a hole of
+  15,300 is filed under 14,336 and serves nothing above 14,336. With sizes spread ±7 % around
+  15,000 a hole of the same class as the request fails it more often than not. This is
+  `allocator_run_size_for`'s note ("a run of 68 is filed under 64, a request for 68 looks from 72")
+  met at scale: 63–80 % of refusals had a hole that fit.
+- **Raw-size requests splinter holes.** A 14,200-word request accepted from a 15,300 hole leaves
+  1,100 free words no page will ever use; the count of holes grows to half the resident count
+  (1,895 at 4,096) and free space that is plentiful in total is useless in any one place: the
+  remaining 20–37 % of refusals.
+
+Quantizing the request to `allocator_run_size_for(size)` closes the first entirely — for every
+size, `roundDown(run_size_for(s)) === roundUp(s)` (checked exhaustively to 2²² and at the u32
+edges), so a freed run of a class is looked up from exactly that class's bin — and most of the
+second: a bin-sized request consumes an *uncoalesced* bin-sized hole whole. Coalesced holes still
+splinter (two freed 16,384 runs make 32,768, a 15,360 request leaves 17,408, a 16,384 request from
+that leaves a 1,024 splinter), which is what the 56–194 residual holes are. Zero refusals over
+8,192 events at every size; holes down 4–10×. Overhead measured over 100,000 page-shaped draws:
+**3.41 % of data words, 3.93 % of rows**; 4.3 % mean over log-uniform sizes; 12.06 % worst over
+1 K–4 M. Bin-sized and power-of-two clients pay nothing, and bins are fixed points of
+`allocator_run_size_for`, so `grow_target_for` and the growth ladder are unaffected.
+
+### 2.2 How often the manager compacts, and what it costs
+
+`GPUMeshletManager` as it stands, `compact()` wrapped and timed (wrapping is fine in a scratch
+driver; the bench spec reads the same facts off `stats`, §4.7):
+
+| resident | churn events | arena headroom at churn start | compactions | events per compaction | compact p50 | compact max | per record | growths |
+|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| 512 | 1,024 | 190 % | 0 | — | — | — | — | 0 |
+| 1,024 | 2,048 | 78 % | 0 | — | — | — | — | 0 |
+| 2,048 | 4,096 | 21 % | 0 | — | — | — | — | 1 |
+| 3,300 | 6,600 | 22.6 % | 5 | 1,320 | | | | |
+| 3,700 | 7,400 | 10.3 % | 6 | 1,233 | | | | |
+| 4,096 | 8,192 | **0.2 %** | **356** | **23** | **115 ms** | 209 ms | **28 µs** | 3 |
+
+(The 3,300 and 3,700 rows are the policy reviewer's re-run of the same driver with the fill varied
+against the same 62.5 MB arena.)
+
+The per-record figure matches the Zorah trace (79–115 ms at ~4,100 records is 19–28 µs a record)
+— the cost is the CPU re-encode and upload of every record's rows, not the copy. Compaction was
+99 % of the churn's wall time at 4,096; every `add_batch` that did not compact took 30–50 µs (the
+same serde, once) and every `remove_batch` 1.5–3.5 µs.
+
+Headroom is the variable. Growth is `max(grow_target_for, +16 K words, ×1.25)`, a ladder of
+32 → 40 → 50 → 62.5 MB; where the fill stops on that ladder is where the headroom lands, and a
+rebuild re-packs to the same size, so it *restores* that headroom rather than adding to it. The
+Zorah tour's four compactions over ~3,009 turnovers (≈ 750 events each) sit between the 10 % and
+23 % rows; the 0.2 % row is what a fill that lands just under a rung looks like — 23 events per
+rebuild — and it is one ladder step away from any scene.
+
+### 2.3 Headroom against refusals
+
+Bare allocator at 4,096 resident, headroom over *reserved* words (the quantized arena sized from
+the quantized live set; the first draft sized it from raw words and read 3.4 % low):
+
+| headroom | raw: refused (fitting / fragmented) | quantized: refused |
+|---:|---|---:|
+| 0.3 % | 748 (477 / 271) | 50 |
+| 1 % | 703 (442 / 261) | 15 |
+| 3 % | 639 (406 / 233) | **0** |
+| 6 % | 516 (322 / 194) | **0** |
+| 12 % | 269 (186 / 83) | **0** |
+
+Quantized requests need ~3 % headroom over reserved (≈ 6.5 % over true bytes) to never refuse
+under this load; raw requests refuse at every headroom. So the policy has to leave headroom
+(growth's 25 % does) and must not pack it away.
+
+### 2.4 A load the sweep is for
+
+Under §2.1–2.3, quantization plus grow-on-refusal leaves the motivating load with zero refusals,
+so the sweep would be exercised by nothing above. The load it is for is **mixed classes with a
+large record swapped under small churn**: the page churn of §2 plus, every `K` events, one of the
+six statics removed and re-added one class larger (an editor swapping an asset; a crowd's new
+character type). Each swap's request finds its old hole one class too small and the small churn
+has carved the tail. Numbers for that load — refusals, growths, rebuilds with steps 1–3 alone, and
+then with the sweep — are §8's C3 row's to fill; the bench spec runs it (§6).
+
+## 3. Alternatives, with numbers
+
+| option | what it buys | what it costs | verdict |
+|---|---|---|---|
+| **Quantize requests to bins** (manager-side, `allocator_run_size_for`) | refusals under near-uniform churn: 269 → 0 at 4,096; holes 1,895 → 194; no allocator change; the rebuild's sequential packing becomes exact (a bin request ≤ a remainder is ≤ the remainder's bin), closing a latent refusal `#rebuild` can assert on today | 3.4 % data / 3.9 % rows on page-shaped sizes; 4.3 % mean; ≤ 12.5 % worst | **take**. Generic: every recurring size class benefits, every client pays the same bounded ratio |
+| **Byte-level row patch** | rebuild and `add_batch` per-record cost 28 µs → the copy and one add per row | none | **take** |
+| **Quantize + grow-on-refusal + fast rebuild, no sweep** | zero refusals under the motivating load; a rebuild, when one fires, at ~1/6 the cost | fragmentation that is not near-uniform still ends in an O(n) event | **taken as the first step**; measured before the sweep is built, so the sweep is proved against what remains |
+| Fix the lookup in `OffsetAllocator` (also walk the bin below, first node ≥ size, bounded to K) | zero overhead | probabilistic (holes in one bin are ~uniform in [bin, next), a request in the upper part misses most of them; K = 8 finds one ~97 % of the time under this load and less under others), changes a shared O(1) allocator's contract, does nothing about splintering | reject |
+| Size classes / regions per client | perfect recycling for one class | the manager would have to know the classes — exactly bending it to one client's shape; mixed clients still fragment across regions | reject; quantization is the class-free form of the same idea |
+| Grow instead of compact when fragmentation is not what refused | no-op with quantization: the "fitting hole refused" class stops existing, so every remaining refusal *is* fragmentation | — | subsumed by §4.4 |
+| Incremental rebuild (the two-buffer rebuild spread over frames) | keeps the packing order | two buffers live for the duration and every shader binds one; not viable | reject |
+| Re-allocate-based hole filling ("moving tail": `allocate`, copy, `free` the old range; no new primitive) | no allocator change | the allocator's bins are LIFO with no address order, so a re-allocation is not lower by construction, and it can never merge two splinters into one run — which is exactly the refusal quantization leaves | reject |
+| **Sliding compaction in place** (§4.2–4.3) | O(1) allocator step, bounded moves per frame, no second buffer, the free space consolidates as one growing run behind the cursor | a new allocator primitive; a staged copy per moved record; `changed` per moved record within the budget | **take**, as the second step |
+| A synchronous budgeted sweep before growing | avoids a growth when a few moves would do | the data move's address patch is a compute dispatch and needs a `ShadeGPUCommandContext`, which the manager cannot make from the `GPUDevice` it holds; a CPU-patched row re-upload instead would overwrite the bounds the skinning pass writes on the GPU | **not in this plan** (§7); the natural refinement once a `GraphicsContext` is threaded through `GPUGeometryManager` |
+| Full rebuild only (status quo) | simplest | 115 ms every 23 events at 4,096 resident with 0.2 % headroom, 79–115 ms four times a tour on Zorah | the defect |
+
+Budget, provisional until C3 measures a move: `MOVE_BUDGET = 64` records and
+`WORD_BUDGET = 1,048,576` words (4 MB of data) per `sweep`, whichever is hit first, and never
+less than one move when one is possible; `STEP_BUDGET = 4,096` cursor steps a call. A move is an
+O(1) slide, four copy encodes, `meshlet_count` pairs in a patch table and one `changed`; at a
+projected ~3–5 µs that is ≤ 0.35 ms of main thread a frame while a sweep runs, and a sweep of
+4,096 moved records completes in 64 frames. The constants are counts because that is what the
+code bounds; §8's C3 row records the measured ms and MB they come to, and they are re-picked from
+that. A forced move of a 2.4 M-word static (one move over `WORD_BUDGET`) is 19 MB of GPU copy and
+a 5,600-pair patch — not a hitch.
+
+## 4. Design
+
+### 4.1 Quantization and the row patch
+
+`#allocate_data_and_metadata(data_size_words, meshlet_count)` allocates
+`allocator_run_size_for(data_size_words)` and `allocator_run_size_for(meshlet_count)`. The record
+keeps `data_size` and `meshlet_count` as the true sizes — every copy, patch and readback uses
+those — and the allocator's node keeps the rounded size, which is what `free` returns to the bins.
+`#rebuild` rounds the same way. `add_batch` asserts both sizes non-zero (a zero-size node has no
+place in a partition; `clone_batch_allocation` already asserts it). `gpu_memory_usage_occupied`
+keeps reporting true bytes; `gpu_memory_usage_reserved` reports what the arenas have handed out,
+so the overhead is a number rather than a claim.
+
+`#write_patched_metadata` becomes a byte copy of `metadata_buffer_original` with one `u32` add at
+word 6 of each 40-byte row (`MESHLET_METADATA_STRUCT` is packed, `size === aligned_size === 40`,
+pinned by a spec that fails if the layout ever changes), then one `queue.writeBuffer`.
+
+### 4.2 `OffsetAllocator` primitives
+
+Node indices are already API (`Allocation.metadata`, `free_node`). Four additions, all O(1), none
+consuming a node:
+
+- `slide_down(node_index) → delta`. `node_index` must be a used node. If its address-predecessor is
+  a free node of size `F`, the two swap places: the used node's offset drops by `F`, the free node's
+  offset rises by the used node's size; the free node's size — and therefore its bin — is
+  unchanged, so no bin-list surgery. If the free node now adjoins a free successor the two are
+  merged: both removed from their bins *before* either changes size (`#removeNodeFromBin` finds the
+  bin from the node's current size), then one combined node inserted — one node back on the
+  freelist. Head and tail tracking are updated. Returns `F`, or 0 when the predecessor is used or
+  absent. The merge is the common case, not the exception: every record whose allocation left a
+  remainder has a free successor until something fills it.
+- `first_used_node() → node_index | ALLOCATOR_NO_SPACE`, `next_used_node(node_index) → …`. Address
+  order. Free nodes coalesce, so at most one free node sits between two used ones and each is a
+  walk of at most two links. `first_used_node` needs the node that starts the chain; `#head_node`
+  is the node whose `NEIGHBOR_PREV` is unused, maintained where the chain's first link changes
+  (`reset`, `free_node`'s combined node, `slide_down`) — from the link, not from the offset, so a
+  zero-size node at offset 0 cannot mislabel it.
+- `can_allocate(size) → boolean`. Exactly `allocate(size)`'s own refusal test, without allocating:
+  the freelist is not empty *and* a bin at or above `roundUp(size)` is non-empty. Node exhaustion
+  is the one shortfall no arena size fixes, and a probe that ignored it would send the manager to
+  grow for nothing.
+
+Invariants `slide_down` preserves, and the spec pins over a randomized sequence of allocate / free /
+slide / grow against a reference model: the nodes partition `[0, size)`; free nodes never adjoin;
+every free node is filed under `roundDown(size)` and every `usedBins` / `usedBinsTop` bit is set
+iff its bin is non-empty; `freeStorage` is the sum of free node sizes; `freeOffset` is
+`maxAllocs − 1 − nodes in the chain`; `#head_node` / `#tail_node` name the nodes starting / ending
+the chain; no node is consumed by a slide and one is returned by a merge. `#tail_node`'s comment
+that `#insertNodeIntoBin` is the only writer of an end offset is amended: `slide_down` is the
+second, and a missed tail update would orphan the free node on the next `grow` silently — so the
+tail spec asserts that after sliding a tail record of size `s` over a free `F` and growing by
+`d`, `freeOffset` is unchanged (the free-tail path spends no node) and `allocate(F + d)` lands at
+the free node's post-slide offset.
+
+### 4.3 The sweep
+
+Per arena the manager keeps two pointers, each a used node's index or `NONE`: the **cursor** of
+the running pass, and the **restart** — the used node after the lowest hole opened below the
+running pass (or, with no pass running, since the arena was last packed). `remove_batch` keeps
+both — before freeing: a pointer on the removed node moves to the node after it; a hole below the
+cursor and below the restart's record moves the restart there. A pass that reaches the arena end
+with a restart pending starts again from it, in the same episode; one with none ends the episode.
+So a sweep needs no prefix walk to find its first hole, and holes opened under a running pass are
+closed by the next pass in one walk. (Revision 2 stepped the cursor *back* on every removal below
+it; under a pool that thins fast that sent it back under the records it had just packed on every
+removal, and the pass never reached the end — §10.) `#rebuild` clears both. `grow` re-files the
+tail free node and writes one used node's successor link; it renames nothing, so both survive it.
+
+A sweep is **armed** by a fragmentation refusal (§4.4) and runs until the cursor reaches the arena
+end. A step:
+
+```
+node    = cursor
+delta   = allocator.slide_down(node)
+cursor  = allocator.next_used_node(node)        // NONE at the arena end: the sweep is done
+if delta > 0: the record owning `node` moved down by `delta` → §4.3.1
+```
+
+Because sliding puts the free space *after* the moved record, every hole the cursor has passed is
+one free node immediately behind the cursor — the **bubble** — and every record from the first hole
+onward slides over it; a sweep ends with all free space in one run at the tail. Allocations during
+a sweep land wherever the bins say — below the cursor (already packed, since `allocate` hands out
+the *start* of a run), in the bubble (it shrinks; the sweep continues), or above (the sweep
+reaches it). A step that moves nothing (a hole the cursor was stepped back for that an allocation
+has since filled) costs a link walk and counts against `STEP_BUDGET`.
+
+Records are found from nodes by a per-arena `Map<node_index, record>`, maintained through one
+`#release` path for every free the manager does — `remove_batch`, the partial-success release in
+`#allocate_data_and_metadata`, `#rebuild` — because a freed node's index is immediately the merged
+free node's and then the next allocation's, so a stale cursor would name a *different live record*
+and never fail loudly. The step asserts `map.get(cursor).allocation.metadata === cursor`, writes
+the cursor before `changed.send0()`, and re-reads it after — a handler may `remove_batch`.
+
+#### 4.3.1 What a move does
+
+The steps run CPU-side first over the whole batch — slides, record offsets, the list of
+`(old, new, words)` per arena and the `(row, delta)` patch pairs — and the GPU work is recorded
+after, from that list:
+
+1. One transient staging buffer (`COPY_SRC | COPY_DST`) sized to the largest moved range of this
+   batch; every move uses it from offset 0. Copies in one command buffer are ordered, so reusing
+   one region is correct, and a fixed descriptor is what `buffer_allocator_main` pools well.
+2. Per data move, in cursor order: `copyBufferToBuffer(data, old, stage, 0, n)`,
+   `copyBufferToBuffer(stage, 0, data, new, n)`. WebGPU refuses a same-buffer copy and the
+   intra-copy compute shader the clone flush uses is not overlap-safe; a slide by less than the
+   record's size overlaps. Two plain copies are well-defined, execute on the software device (so
+   a spec reads the bytes back), and cursor order means a record only ever slides into space an
+   earlier record vacated, whose read was recorded earlier.
+3. Per metadata move: the same two copies over the rows. The rows are copied, not re-derived
+   from `metadata_buffer_original`, because the skinning bounds chain writes `bounds_box` into
+   clone rows on the GPU every frame and a re-derivation would put rest-pose boxes over deformed
+   vertices — permanently for an unbound clone, which draws frozen at its last pose.
+4. Per data move: `meshlet_count` `(row, delta)` pairs, with `delta = (−F) >>> 0`; one
+   `shader_meshlet_metadata_address_patch` dispatch per batch, after the copies. Same shader,
+   same wrapping add, as the clone flush.
+5. `record.changed.send0()` for every moved record, after the whole batch is recorded.
+
+Everything is in the one `cmd_ctx`, in order, so a pass recorded after `sweep` in the same context
+— or in any later submit — reads rows and data that agree. `sweep` remembers the context it
+recorded into and asserts it is `finished` before the manager allocates, frees, grows or rebuilds
+again: a recorded copy names `old`, and an `add_batch` placed at `old` in the meantime uploads
+with `queue.writeBuffer` *now*, ahead of the copy; a `grow` in the meantime would destroy the
+buffer the copy names. No consumer does either today (§5 says where the calls sit), and the assert
+is what keeps it that way.
+
+### 4.4 Refusal policy
+
+`#allocate_data_and_metadata`, per attempt (three attempts, as today):
+
+1. Allocate both (quantized). Both land → done. A partial success is released through `#release`.
+2. For each refused arena, classify: **fragmented** if `freeStorage ≥ allocator_run_size_for(size)`
+   (a sweep can help: with that much free and a refusal there are at least two free nodes), else
+   **short**.
+3. Fragmented and no growth yet in the current sweep episode: arm the sweep if it is not armed,
+   `grow` (25 % headroom, moves nothing; `grow_target_for` is minimal and the manager's ladder
+   rounds it up), note the growth against the episode, retry.
+4. Fragmented and the episode already grew — a second fragmentation refusal before the sweep
+   finished, the case the reviewers named (an editor re-adding a large asset each time small churn
+   carves the tail) — `compact()`: bounded now by §4.1, ~3–5 µs a record, and it ends the episode.
+   Retry.
+5. Short: `grow`, retry. (A refusal with a full freelist is short by this test only if the arena
+   is full too; a node-exhausted allocator with room is fragmented-but-unsweepable — `grow` then
+   changes nothing, and attempt three's `compact()` re-picks the node budget. Stated so it is not
+   a surprise; §6 pins it.)
+6. Still refused (growth stopped at `maxBufferSize`): `compact()`, then the existing throw. On an
+   adapter that hands out 256 MB this is the status quo, at a sixth of the cost.
+
+An episode is: armed by a fragmentation refusal **or by scatter** — a removal that leaves at least
+an eighth of the arena free in pieces (free space less the largest free run, both from the bins,
+O(1); and at least 16 K words or 512 rows that way) arms the sweep by itself, so the tail is clear
+by the time a large arrival needs it rather than after the growth it forced (§10) — and ended by
+the sweep reaching the arena end with no restart pending, or by a rebuild. Memory: the high-water mark is reserved × 1.25 plus the momentary old+new pair a `grow`
+already costs; +25 % once per episode against the status quo's rebuild-in-place, then the sweep
+puts that headroom at the tail where the next growth would otherwise be, so an episode that
+recurs finds room before it refuses. On the Zorah ladder the arena is unchanged unless
+quantization's +3.4 % crosses a rung. `#deallocations_since_last_rebuild` goes: growth guarantees
+progress, and the counter's job — "do not rebuild for nothing" — is done by `freeStorage`.
+
+`compact()` stays public and unchanged in meaning (full synchronous rebuild), for a caller at a
+level boundary who wants the arenas packed now. The manager itself reaches it only in steps 4–6.
+
+### 4.5 `sweep(cmd_ctx)` and `update(cmd_ctx)`
+
+Two methods, because `update` is called three times a frame in the renderer (`GraphicsContext.
+update` at the head of `#begin_frame`, `GPUSceneContext.build`, and `GPUMeshSkinningContext.update`
+directly) and a per-frame bound has to have one call site:
+
+- `sweep(cmd_ctx)`: one budgeted step per arena (budgets shared across the two), nothing when no
+  sweep is armed. Called by `GraphicsContext.update` once per frame, before `geometries.update`.
+- `update(cmd_ctx)`: the clone flush, as today. Reads whatever offsets the records hold, so a clone
+  queued before a sweep in the same frame copies from post-sweep offsets.
+
+### 4.6 What stays the same
+
+Records, the `changed` signal, `add_batch`/`remove_batch`/`clone_batch_allocation`/`update`/
+`grow`/`compact`/`destroy`, the buffers being replaced by `grow` and `compact` only, the O(1)
+`remove_batch`, the pending-clone rules (a queued clone names records, and cancellation by either
+record), `ALLOCATION_LIMIT`. A move consumes no allocator node.
+
+### 4.7 `stats`
+
+A read-only `stats` object: `growths`, `rebuilds`, `moves`, `sweeps_armed`, `sweeps_completed`,
+`moves_last_sweep`. Public because the bench spec, the tour and a host's overlay all need "did the
+rebuild path fire" without a spy, and because a sweep that arms and never completes is a defect
+nothing else would show.
+
+## 5. The consumers' contract
+
+What the manager guarantees:
+
+- **`changed` fires when, and only when, `record.data.offset` or `record.metadata.offset` has
+  changed**, synchronously, with the new offsets already on the record. A consumer that holds only
+  `metadata.offset` — every consumer today — compares before acting; a data-only move changes
+  nothing it holds. It fires from inside `sweep(cmd_ctx)` and from inside `compact()` (which an
+  allocation may reach, §4.4). (Today it fires only for a data move, from `compact()` alone; a
+  rebuild that moved a record's rows but not its data sent nothing, which the VG pool would have
+  missed.)
+- **Per `sweep` call, at most `MOVE_BUDGET` records move**, and the renderer calls it once per
+  frame. A `compact()` moves every record; the manager reaches it only as §4.4 says, and `stats`
+  counts it.
+- **The bytes are where the offsets say by the time anything recorded after the move runs.** A
+  move recorded into `sweep`'s `cmd_ctx` executes with that command buffer, rows and data and
+  address patch in order; a consumer that publishes an address with `queue.writeBuffer` any time
+  before that command buffer is submitted is consistent, and one that records an address into a
+  command buffer must record after `sweep` — which is the order the renderer has: `sweep` at the
+  head of `Renderer.#begin_frame`, the VG runtime's `begin_frame` flush (a `FrameStart` graph
+  extension) and every pass after it. VG installs, the one allocating path that is not a scene
+  build, run from a readback promise between frames.
+- **Nothing allocates, frees, grows or rebuilds between a `sweep` that recorded moves and that
+  context's `finish`** — asserted by the manager (§4.3.1). The renderer's three contexts each
+  finish with no allocation in between.
+
+What each consumer does:
+
+| consumer | holds | today | change |
+|---|---|---|---|
+| `GPUGeometryManager` | `metadata.offset` in the geometry table row per source and per clone | `console.warn` + TODO on sources; no listener on clones | the `changed` handler compares the offset and `queue.writeBuffer`s that one `GEOMETRY_METADATA_STRUCT` row into `buffer_metadata` — inside the handler, not deferred to its own `update`, because the skinning context's direct `meshlets.update` is not followed by one and a deferred patch would leave the row stale for the frame; skipped when `__needs_update` is set (the rebuild writes every row) or the row is past the buffer (same). Clones get the listener too; `remove`/`remove_clone` remove it. |
+| `GPUVirtualGeometryPool` | `MESHLET_BASE` per page row | listens; writes the word, marks the arena; flushed at the runtime's `begin_frame` | none |
+| `GPUMeshSkinningContext` | `source_meshlet_metadata_offset`, `clone_meshlet_metadata_offset` per binding; `prev_position_offsets` keyed by absolute clone row | does not listen — today a `compact()` with a skinned mesh resident silently deforms the wrong rows | listen on both records per binding (unsubscribe closures kept on the binding and run by `#drop_binding_at`, as the VG pool does): on a metadata offset change, `#bindings_dirty = true`. `update` then re-derives every binding's offsets from its records and **rebuilds the whole prev-position offsets table from the bindings** (capacity ensured to the highest new row) before the wholesale upload it already does. Rebuilding rather than re-keying per listener, because a rebuild's `changed` order is insertion order and one binding's new rows can be another's old rows. The prev-position *history* lives in a side buffer keyed by word offset and is untouched, so no frame of motion vectors is lost. |
+| BLAS (`GPUGeometryMeshletsBVH`, `bvh_to_gpu_buffer`, `GPUBLASRefitBatch`) | batch-local meshlet indices; the refit reads `geometries[i].meshlets_address` on the GPU | — | none beyond the geometry row being right |
+| anything holding `buffer_data`/`buffer_metadata` | the buffer objects | replaced by `grow`/`compact` already; re-read per frame | none — a sweep never replaces a buffer |
+
+## 6. Proof
+
+Every spec is written red first against the code before its ledger row, in
+`GPUMeshletManager.spec.js` / `OffsetAllocator.spec.js` / the consumers' specs, no spies or mocks,
+asserting the public API, `stats`, or what reaches `SoftwareGPUDevice` (copies and `writeBuffer`
+execute there; compute dispatches are recorded and their bound buffers are readable before
+`finish`).
+
+**`OffsetAllocator`** (all red today — the methods do not exist):
+- `slide_down` over a randomized allocate / free / slide / grow sequence against a reference model
+  checking every §4.2 invariant, bin bitmasks and freelist count included.
+- `slide_down` merges the free node with a free successor and returns a node to the freelist.
+- the tail case as §4.2 states it; sliding over the head leaves the used node as head.
+- `first_used_node`/`next_used_node` walk exactly the used nodes in address order, across frees.
+- `can_allocate` agrees with `allocate` on both sides of a bin boundary **and** on a node-exhausted
+  allocator with room.
+
+**`GPUMeshletManager`**:
+- *quantization*: a batch of size `S` (not itself a bin) freed, and one of `S + 1` in the same bin
+  arriving with the tail shorter than the bin gap, lands in the hole: `buffer_data` is the same
+  object (a rebuild replaces it at the same size) and the record's offset is the hole's. Red: the
+  raw request is refused and rebuilt for.
+- *the row patch*: `add_batch` on the device holds the same rows the serde produced (`gpu_addresses`
+  agrees with the old code's output pinned as bytes); a layout spec fails if `size`,
+  `aligned_size` or `address`'s offset in `MESHLET_METADATA_STRUCT` change.
+- *bounded sweep*: with `N > MOVE_BUDGET` records above one hole, after the refusal that arms it,
+  one `sweep` fires `changed` for exactly `min(N, MOVE_BUDGET)` records and copies at most
+  `WORD_BUDGET` words; the next continues; after `ceil(N / MOVE_BUDGET)` calls every record is
+  packed, the free space is one tail run (an `add_batch` the size of the whole freed space lands
+  with `buffer_data` the same object), and `stats.rebuilds` is 0. Red: the rebuild moves all of
+  them at once and replaces the buffer.
+- *a move carries the bytes and re-addresses the rows*: after a sweep, `gpu_data_words` agrees with
+  the record's new offset, the metadata rows at the new metadata offset are the old rows (copied,
+  not re-derived: a row whose `bounds_box` was overwritten on the device by a `writeBuffer` in the
+  spec keeps that box), and the patch dispatch's table names exactly the moved rows with the right
+  deltas (read off the bound buffer before `finish`; the software device does not run the shader).
+- *overlapping move*: a record sliding down by less than its own size arrives intact.
+- *records not moved keep their offsets and get no `changed`* (inside the bounded-sweep spec).
+- *refusal policy*: the existing "a request the arena has room for in pieces is compacted for, not
+  grown for" is **rewritten** to the new contract — it is grown for, once, and after the sweep the
+  next such request lands without a second growth and without a rebuild (`stats`); a second
+  fragmentation refusal mid-sweep is answered by exactly one rebuild; node exhaustion with room
+  ends in a rebuild rather than a throw.
+- *cursor under removal*: removing the record the cursor names, and removing records above and
+  below it mid-sweep, ends with every record packed and one free run (the §4.3 postcondition).
+- *the record-and-allocate rule*: an `add_batch` between a `sweep` that recorded moves and the
+  context's `finish` throws.
+- *clones*: the existing "a queued clone survives the compaction" case is kept (explicit
+  `compact()`); a new case queues a clone, sweeps the source down in the same context via `sweep`
+  then `update`, and reads the flush's regions table off the dispatch's bound buffer (captured
+  before `finish`) to check it names the post-sweep offsets.
+- *the three named cases stay green*: clones surviving compaction, growth leaving records in
+  place, O(1) `remove_batch`.
+
+**Bench spec** `GPUMeshletManager.bench.spec.js` (the repository's `*.bench.spec.js` form):
+- per-`sweep` cost at 1,000 and at 32,000 resident records with identical work per call
+  (`MOVE_BUDGET` moves of 4-word records, so the software device's copies do not dominate),
+  paired, alternated, minimum of rounds; the difference — the O(N) signature a walk of 32,000
+  records would leave, ~30–60 µs — asserted under 10 µs.
+- the §2 churn at 4,096 (quarter scale) asserting `stats.rebuilds === 0` and `changed` per `sweep`
+  ≤ `MOVE_BUDGET`; the §2.4 mixed load asserting the same, and recording growths.
+
+**Consumers**: `GPUGeometryManager.spec.js` — after a `compact()` moves a registered geometry
+and a clone, the geometry table rows on the device carry the new `meshlets_address` (red: the
+rows are stale). `GPUMeshSkinningContext.spec.js` — after a `compact()` moves a clone (and a
+source), the uploaded bindings carry the new offsets and the prev-position table is keyed by the
+new rows, driven through the spec's own `frame()` (red today); and a dropped binding's records
+moving afterwards write nothing.
+
+**The Zorah tour** (`tour.mjs`, RUNTIME_PLAN_2026_09_14 §7's recipe): eight rosettes, five seconds
+each, twice round, at 4,096 slots, headless Chrome. Recorded per sample: `stats`,
+`gpu_memory_usage` / `_reserved` / `_occupied`, long tasks, frame p50/p95. Pass: zero main-thread
+tasks over 50 ms attributable to the manager (the vite worker-module stalls in the first seconds
+are the runtime plan's known other source; a long task in a later sample is the manager's until
+shown otherwise), `stats.rebuilds === 0`, page turnover of the same order (~3,000), `refused` not
+worse, p50/p95 not worse than 8.3/12.6 ms. And, because under this load the sweep is expected to
+have nothing to do, a second browser scenario in the same page: the §2.4 swap load driven through
+`scene_context.geometries.meshlets` from the driver, asserting `stats.moves > 0`,
+`stats.rebuilds === 0` and the same long-task bar.
+
+## 7. What this does not do
+
+- **No synchronous sweep before growing.** §3 says why; the cost is one 25 % growth per episode.
+- **No shrinking.** An arena grown under fragmentation keeps its size after the sweep reclaims the
+  space; the reclaimed run at the tail is what later growth would have asked for. Shrinking is a
+  buffer swap, i.e. a `compact()`, and a caller who wants it has that.
+- **No sweep below an eighth of scatter.** A pool whose holes are recycled as fast as they are
+  made — near-uniform churn under quantization — stays under the ratio and is left alone; the
+  sweep is for a pool that thins. The ratio is a constant, not a knob.
+- **`compact()` still re-derives rows from CPU bytes**, so it resets any `bounds_box` the skinning
+  chain wrote — as it always has. A sweep does not; that is why rows are copied (§4.3.1).
+- **No packing-order guarantee.** The rebuild packed in insertion order; the sweep packs in
+  address order.
+- **No change to `ALLOCATION_LIMIT`** or to the node budget's meaning. A slide consumes no node.
+- **No change to what a `MeshletBatch` is** or to the metadata row layout.
+
+## 8. Ledger
+
+All on the software device at a quarter of the Zorah sizes unless said otherwise; every spec was
+red against the code before its row.
+
+| # | item | spec (red first) | measured / commit |
+|---|---|---|---|
+| C2 | manager: quantized allocation, byte-level row patch, empty batches reserve one element, `gpu_memory_usage_reserved`, `stats`, `allocation_limit` option | `GPUMeshletManager.spec.js` | the §2 churn at 4,096: 356 rebuilds → 0; `add_batch` 39 → 19 µs; a rebuild of 4,102 records 28 → 6.5–7.0 µs a record — `3de80c278`, `89ae26912` (the empty-batch fix rode with C4: the assert refused eleven scene-row and cut specs) |
+| C4 | manager: refusal policy (grow once per episode → rebuild → throw), counter removed, the "compacted for" spec rewritten | `GPUMeshletManager.spec.js` | three cases: grown for once and nothing moves; a second refusal mid-episode is one rebuild; out of nodes with room is a rebuild, not a throw — `89ae26912` |
+| C7a | bench spec: the §2 churn against C2 + C4 and the §2.4 phase load | `GPUMeshletManager.bench.spec.js` | churn: 0 rebuilds, ≤ 6 growths; phase load without a sweep: 2 episodes, 4 growths, 0 rebuilds, 68.8 MB over 42.1 MB reserved — `10d3eaa85` |
+| C5 | `GPUGeometryManager`: row patch in the handler, listener on clones, removal | `GPUGeometryManager.spec.js` | two cases — `36116320c` |
+| C6 | `GPUMeshSkinningContext`: listeners, table rebuilt from bindings, unsubscribe | `GPUMeshSkinningContext.spec.js` | one case (the binding named the clone's old row) — `f6119fb4f` |
+| C1 | `OffsetAllocator`: `slide_down`, `first_used_node`, `next_used_node`, `can_allocate`, `#head_node` | `OffsetAllocator.spec.js` | six cases and a 4,000-step randomized sequence — `42b2af34a` |
+| C3 | manager: cursors, one release path, `sweep(cmd_ctx)`, the record-then-allocate assert, `GraphicsContext.update` calls it | `GPUMeshletManager.spec.js` | eight cases; the §6 list as written — `892e27197` |
+| C7b | bench spec: the phase load with the sweep, the paired per-`sweep` cost | `GPUMeshletManager.bench.spec.js` | one sweep of 64 moves: 481 µs at 1,000 resident, 402 at 32,000 (noise-dominated, then re-measured under C3b: 135 vs 138 µs); the phase load with a refusal-armed sweep grew 4 times, as without — the finding that made C3b — `044b8f779` |
+| C3b | manager: the sweep arms itself on an eighth of scatter; the restart pointer replaces the step-back | `GPUMeshletManager.spec.js` | one case (three holes arm, two do not); phase load with the sweep: 24 episodes armed and finished, 126,990 moves at ≤ 64 a call, 3 growths and 67.5 MB where the pool that could only grow had 4 and 68.8 — `fe97c55fe` |
+| C8 | Zorah tour and the phase scenario on the live pool, numbers into §10 | `H:/tmp/tour_out_c8/rows.json` | see §10 |
+
+## 9. Review
+
+Three disjoint reviewers on revision 1, 2026-09-16, before anything was built. What they found
+and what it changed:
+
+**Allocator primitive** (8 findings). `can_allocate` as a bare bin probe ignored node exhaustion
+(`allocate` refuses on an empty freelist first) — fixed in §4.2 and §4.4 step 5. A removal *below*
+the cursor left a second free run the sweep never revisited, breaking the bubble claim — fixed by
+the cursor step-back rule in §4.3. `#head_node` tagged by offset mislabels after `allocate(0)` —
+derived from the chain link instead, and the manager asserts non-zero sizes. The merge inside
+`slide_down` has to remove both nodes before either changes size, and insert last — stated. The
+tail spec as first written could pass with the tail stale — strengthened. The quantization identity
+holds per uncoalesced hole only — reworded, with the coalesced counterexample. A stale cursor
+names another live record and never fails loudly — one `#release` path, an assert in the step, and
+the cursor re-read after `changed`. `grow` keeps the tail node's index (a nit; the claim was that
+the cursor survives it, which it does).
+
+**GPU ordering and consumers** (12 findings). Two blockers: the skinning context calls
+`meshlets.update` directly and nothing runs `geometries.update` after it, so a deferred row patch
+left the geometry table stale for that frame — the row is now patched inside the handler; and
+`update` runs three times a frame, so "at most `MOVE_BUDGET` per frame" was false by 3× — the
+sweep is its own method with one call site. Re-deriving rows from CPU bytes on a move would
+overwrite GPU-written skinning bounds — rows are copied. The skinning listener as first described
+corrupted another binding's rows under a rebuild's insertion-order `changed`, and listeners were
+never removed — the table is rebuilt from bindings, and bindings unsubscribe. The plan had not
+stated that nothing may allocate between a recorded move and the context's `finish` — stated and
+asserted. The staging buffer is sized to the largest move and reused; the sync sweep could not
+have had a transient buffer at all, which with the address-patch dispatch is why it is gone. The
+consumer specs could not arm a sweep through `GPUGeometryManager`'s default-sized manager — they
+drive `compact()`, which exercises the same `changed` contract. The regions-table check must
+capture the bound buffer before `finish`. A file name was wrong.
+
+**Policy, measurement, proof** (11 findings). The 4,096 row was a fill landing 0.2 % under a
+ladder rung, and the Zorah tour's ≈ 750 events per compaction sits with the 10–23 % rows — the
+headroom column and the reconciliation are in §2.2. Under the plan's own numbers the motivating
+load never reaches the sweep — §0 now lands quantization and the policy first, measures, and
+builds the sweep against the §2.4 load it is for; §3 has the no-sweep row. §2.3's quantized
+column was sized from raw words — re-run over reserved; "~6 %" became "~3 % over reserved". The
+policy grew on every unsatisfied refusal with nothing bounding a second growth mid-sweep — one
+growth per episode, then the (now cheap) rebuild. Budgets were projections presented as
+measurements — marked provisional and re-picked from C3's numbers. `STEP_BUDGET` capped a walk
+the manager can avoid — the cursor is maintained on every removal. "Zero rebuilds" was
+unobservable without a spy — `stats`. Several specs were green against today's code as written —
+each now states the red condition. The tour's long-task bar is confounded by the vite worker
+stalls — attributed. The moving-tail alternative was missing from §3 — added and rejected.
+Prev-position history is not lost on a move once rows are copied rather than re-keyed (resolved
+by the ordering reviewer's fix). Numbers in §2.1 that did not match the bench are corrected.
+
+## 10. As built
+
+Nine commits on master, `e002fd5d2` (this document) to `fe97c55fe`, 2026-09-16; the specs in §6
+as written, with the changes below; 5,350 specs green across `src/shade/renderer`, the playgrounds
+and `src/core/binary`; the declaration gate at its budget of 19 throughout.
+
+### 10.1 The Zorah tour
+
+`tour2.mjs` (the runtime plan's driver with the `compact()` wrapper replaced by `stats`), headless
+Chrome, the vite server of this checkout, the range server on the Zorah directory, the same
+container at 4,096 slots, eight rosettes held five seconds each, twice round, then the rest pose;
+then the §2.4 phase load driven through the pool's API from the page while the tier kept
+churning underneath (1,024 synthetic pages, six phases of grow-by-half / thin / import, a moment
+between the thinning and the import). `H:/tmp/tour_out_c8/rows.json`.
+
+| | before (RUNTIME_PLAN_2026_09_14 §7) | after |
+|---|---:|---:|
+| main-thread tasks over 50 ms, whole tour | 4 in 150 s, 79–115 ms, every one a rebuild | **0** |
+| rebuilds | 4 | **0** |
+| page turnover (evictions) | 3,009 | 3,050 |
+| frame time zoomed in, p50 / p95 | 8.3 / 12.6 ms | 4.2 / 4.3–8.4 ms |
+| sweeps | — | 1 armed (by scatter, round 1 stop 3), 1 finished: 3,411 moves inside one five-second sample, no long task |
+| growths over the tour | — | 10, to 244.7 MB over 236.5 MB reserved (224.1 MB occupied) |
+| `refused` (the residency's counter) | 999 | 1,725 — see below |
+| phase load on the live pool | — | 6 episodes armed, 6 finished, 16,058 moves, 3 growths (capacity: 90 MB of synthetic pages), 0 rebuilds, 0 long tasks, p95 8.3 ms |
+| page errors | 0 | 0 |
+
+The residency's `refused` — installs the VRAM tier turned down — is higher than the runtime plan's
+tour recorded. The pool's own counters rule out the pool: no allocation failed (growth answered
+every shortfall), no rebuild ran, no move happened during the samples where the count rose. The
+frames ran at half the period of the earlier tour, so the tier took about twice the readings over
+the same five seconds per stop, and a full tier refuses per reading; that is the likely reading,
+and it is not established here. It is open, and it is the residency's number, not this manager's.
+
+### 10.2 What the build changed against revision 2
+
+- **The cursor does not step back; a restart pointer does** (§4.3). The step-back rule the
+  allocator review asked for is correct for one removal and wrong for a stream of them: the
+  phase load's thinning sent the cursor back under the records it had just packed on every
+  removal, and no pass ever reached the end. A pass now finishes, and the used node after the
+  lowest hole opened below it starts the next, which closes every hole the first left behind in
+  one walk. The randomized allocator spec and the "cursor under removals" spec pin the same
+  postcondition either way.
+- **The sweep arms itself on scatter** (§4.4, C3b). A sweep armed only by a refusal grew exactly
+  as often as no sweep at all, because it reclaimed the space after the growth it could have
+  prevented and the next fill carved the tail before the next arrival. An eighth of an arena free
+  in pieces arms it; under the Zorah tour that happened once.
+- **An empty batch reserves one element rather than being refused.** The non-zero assert the
+  allocator review asked for refused geometries a scene registers with no triangles yet; eleven
+  scene-row and cut specs said so.
+- **The budgets stayed at their provisional values.** A move measured at ~2 µs on the software
+  device (135 µs a call of 64, flat in the resident count); 64 moves and 4 MB a call is a small
+  fraction of a frame on a real device and finished a 3,411-record sweep unnoticed on Zorah.
+- **The bench's phase load gained a settle period** between the thinning and the import, because
+  an import in the very frame after a thousand deletions is not the case the sweep is for and no
+  bounded sweep can have consolidated by then; a large arrival mid-sweep still costs the episode's
+  one growth, as §4.4 says.
+- **Nothing in §5 changed**, and the VG pool needed nothing.