[CLEANUP] Flatten Glimmer reference hot paths (each item cells, inlined track frame, property refs)

[NullVoxPopuli-ai-agent]

What

Six behavior-preserving flattenings of the Glimmer reference / tracking / tag hot paths — the machinery hit on nearly every reference read and every revalidation tick. Found profiling the smoke-tests/benchmark-app table benchmark, but the wins apply to all rendering, not just {{#each}}.

The recurring theme: references and tracking frames were modeled as general compute closures when the data is really just "a value (or parent + path) behind a tag." Storing that as data lets valueForRef/updateRef handle it inline — no closures, and often no tracking frame.

Changes (with isolated per-change impact)

Each number below is an A/B microbenchmark of that change alone, against the prior implementation, through the real valueForRef/updateRef/track (DEBUG=false):

1. Cell reference for {{#each}} block params — item value + index were compute refs (2 closures + a track() frame per read). A cell stores its value behind a fixed tag; no closures, no frame. → 2.3× faster, ~65% less memory (per 1000 items, create+read and update+read).
2. Inlined track() in valueForRef — stop allocating a thunk closure on every recompute (the hottest function in the VM). → ~10% faster, ~33% less garbage per recompute (63.2→57.0 µs/1000, 282→188 kb).
3. Flattened {{#each}} key resolution — resolve the strategy once (not per diff); @index/@key skip duplicate-key dedup entirely; per-pass seen is a plain Map. → index-keyed iteration ~2× faster (48.9→23.0 µs/1000, dedup pass skipped).
4. Property reference for childRefFor — every {{a.b}} was a compute ref with 2 closures holding (parent, path); now stored as data, read/written inline. → ~14% faster, ~25% less alloc (72.2→62.4 µs / 633→477 kb per 1000).
5. Pooled trackers + lazy consumed-tag Set — beginTrackFrame no longer allocates a Tracker + Set per frame (0/1-tag frames are the norm). → common frame 2 allocations → ~0 (0.10 b/iter for the 0-tag case).
6. Fast-path tag [COMPUTE] — subtag-less tags (the majority) return revision directly, skipping the combinator-memoization machinery. → ~17% faster per validate (4.71→3.90 µs/1000).

End-to-end (combined)

tracerbench, control = this branch's base. The changes compound, so this is the combined effect on the revalidation-heavy phases (where the tracking/tag work lands):

Phase	Δ
selectFirstRow1	−38.9% [−44.3 … −33.2]
selectSecondRow1	−14.1% [−19.3 … −9.0]
swapRows2 / swapRows1	−8.0% / −5.9%

Create/clear phases are DOM-dominated, so they stay within noise. No significant regressions.

Testing

Full browser suite green at every step: 9340 tests, 0 fail. CI green.

[NullVoxPopuli]

our each def has a problem, but I'm not convinced this is the solution.

running the bench locally shows not much improvement:

duration phase estimated improvement -21ms [-44ms to -3ms] OR -1.22% [-2.55% to -0.17%]
renderEnd phase no difference [0ms to 0ms]
render1000Items1End phase no difference [-2ms to 1ms]
clearItems1End phase no difference [-2ms to 1ms]
render1000Items2End phase no difference [-3ms to 3ms]
clearItems2End phase no difference [-1ms to 0ms]
render10000Items1End phase no difference [-10ms to 2ms]
clearManyItems1End phase estimated regression +2ms [1ms to 3ms] OR +1.29% [0.65% to 1.95%]
render10000Items2End phase no difference [-20ms to 14ms]
clearManyItems2End phase estimated improvement -3ms [-5ms to -1ms] OR -6.27% [-12.51% to -2.44%]
render1000Items3End phase no difference [0ms to 2ms]
append1000Items1End phase no difference [-2ms to 3ms]
append1000Items2End phase no difference [-2ms to 1ms]
updateEvery10thItem1End phase no difference [-2ms to 2ms]
updateEvery10thItem2End phase no difference [-1ms to 2ms]
selectFirstRow1End phase no difference [-1ms to 1ms]
selectSecondRow1End phase no difference [-1ms to 1ms]
removeFirstRow1End phase no difference [-1ms to 1ms]
removeSecondRow1End phase no difference [-1ms to 1ms]
swapRows1End phase no difference [-1ms to 0ms]
swapRows2End phase no difference [-2ms to 0ms]
clearItems4End phase no difference [-1ms to 0ms]
paint phase no difference [-2ms to 0ms]

I have a hunch we'll need to ship fragment support first so that each can be sort of "off-canvas"'d