Avoid closure allocation in destroy() - #21600

Benchmark: main (bdb2580) vs nvp/perf/destroyable-iterate (20551cf)

Ran via pnpm bench (the krausest js-framework-benchmark scenario in smoke-tests/benchmark-app, tracerbench, 20 samples each, 8x CPU throttle). Negative delta means the PR is faster. Only rows tracerbench marks significant (p < 0.05) are meaningful.

Caveat on the table above: a +58% swing on render1000Items3 (and +10 to 16% on the update phases) is not plausible for a change that only touches teardown, and the benchmark machine had a device-management daemon pinned at 100% CPU during this run. Treat these numbers as noise for now. A rerun on a quieter machine state is queued and will be posted as a follow-up.

Rerun of the benchmark above, same build, same settings, with the machine quieter (load average around 1.7 versus 4 to 5 during the first run). Where this table and the first one disagree, trust the rows that are significant in both.

Benchmark: main (bdb2580) vs nvp/perf/destroyable-iterate (20551cf)

Ran via pnpm bench (the krausest js-framework-benchmark scenario in smoke-tests/benchmark-app, tracerbench, 20 samples each, 8x CPU throttle). Negative delta means the PR is faster. Only rows tracerbench marks significant (p < 0.05) are meaningful.

Correction to my caveat above: the quiet rerun reproduces the first run closely (render1000Items3 +68% vs +58%, remove/swap rows +15 to 18% both times, clear phases 2 to 4% faster both times), so this is a real effect of the change and not machine noise.

The shape is odd though. Total duration barely moves (+1.3% not significant, then +2.1%), while adjacent phases swing hard in opposite directions: selectFirstRow1 is 14% faster and selectSecondRow1 is 12% slower, every clear phase is faster and the phase right after each clear is slower. That pattern usually means the change moved when work happens rather than how much: fewer closure allocations in destroy() shift GC pauses out of the clear phases and into whatever runs next. It could also be that the fn(item, arg) call site in iterate now sees four distinct targets and an arg that alternates between undefined and an object, so it no longer inlines. I have not confirmed either. The tracerbench traces from both runs are available if someone wants to compare GC events per phase before this merges.