[PERF] Cut per-VM allocations in the append VM - #21606

Order-swap check. Same two builds (main bdb2580, PR 8327f61), same settings, run back to back. In the normal run main is tracerbench's control and the PR is the experiment. In the swapped run the URLs are exchanged, so the PR is the control and main is the experiment. The swapped column below has its sign flipped so that in both columns a positive number means the PR is slower. If the effect were positional bias, the two columns would disagree in sign. ✅ marks rows tracerbench calls significant in that run.

n/s = not significant in at least one of the two runs.

Result: every row that is significant in both runs points the same way regardless of which build tracerbench treated as control, so this is not positional bias. The PR is slower on clearItems2, render10000Items1, clearManyItems2 and updateEvery10thItem2, and faster on render1000Items2 and the remove, swap and clearItems4 phases, in both orders.

One correction to my earlier reading of run 2: I said updateEvery10thItem2 "did not reproduce" there because tracerbench did not mark it significant. Looking at the sample summaries, the PR median was 578ms against 286ms for main in that run too, the same doubling as every other run. It failed significance only because the PR samples are bimodal (min about 270ms, max about 660ms), which widens the confidence interval until it crosses zero.

Across all five runs the PR build's samples for this phase have a minimum matching main (about 250 to 290ms) but a median of 580 to 680ms, while main's median stays at 290 to 330ms with only occasional slow samples. So both builds have a fast mode and a slow mode for this phase. On main the slow mode is rare; on this PR it is the common case. That is also why this PR shows visibly more variance than main in every run including the swapped one: the bimodal phase inflates the spread of the whole-run total. It behaves like a major GC that now usually lands inside the second update pass.

Revised branch (023b930): debug snapshots use Array.from instead of spread, and the top() helper is replaced with Array#at(-1) on the stack accessors. Benchmarked against the same main (bdb2580), 20 samples each, 8x CPU throttle. The previous column is run 4 of the earlier version of this branch (8327f61) for comparison. Positive means the PR is slower than main.

Reading: swapping top() for Array#at(-1) changes nothing measurable. Every row that was significant before is significant in the same direction now, with the same magnitudes: render10000Items1 +5 to 6%, clearItems2 +30 to 34%, updateEvery10thItem2 roughly doubled, and the remove, swap and clearItems4 phases 7 to 14% faster. The Array.from change only affects the LOCAL_DEBUG snapshot and was never on the measured path. So the regression is not in how the top of the stack is read. That leaves the allocation-profile change itself (six StackImpl instances per VM becoming six bare arrays) and the execute() loop rewrite as the remaining candidates, and the bimodal updateEvery10thItem2 still points at GC timing.