[chmjkb]

Description

Closes the dispose leaks #60 found in the executor.

• BufferPool tracks the buffers it has handed out and not taken back, so dispose() also frees ones still in use: a captured frame's target or a toArray result nobody released. Each buffer is either free or in use, never both, so trim() (from fix(core): trim the buffer pool so varying input lengths stop piling up GPU memory #58) stays as it is and nothing it destroys is kept or destroyed twice. New check: trim then dispose destroys each buffer once.
• gpuExecutor.dispose() frees its f16/f32 dummies and every scratch buffer, including replaced scratches memoized handles may still bind.
• dispose() also forgets the handles, dummies and scratches it destroys, so an executor used again after it (as bench/ab.ts does after every case) makes fresh ones instead of binding a destroyed buffer. It also ends a capture: the executor can eval and capture again, and a replay() recorded before dispose() throws instead of binding destroyed buffers. New checks: runs again after dispose and runs again after a captured frame is disposed.

The matching checks in eval.gpu.test.ts, replayCache.gpu.test.ts and zoo/leaks.gpu.test.ts drop those buffers from their expected leftovers.

Still left (next PRs)

• gatherRows uploads its index list per dispatch and never destroys it.
• toArray on an eager graph never returns the result buffer to the pool.
• MiniLM's batch path never destroys its segments upload (MinilmModel.forward) or its selector (embedPooledBatch). Its ids and positions are the gatherRows leak above.
• Kernels that make their own uniform instead of using cachedUniform: fixed in fix(core): take every kernel uniform from cachedUniform so none outlives its executor #62.

replayCache.dispose() disposing each bucket's executor is not in this PR any more: #58 made the same fix on main.

Introduces a breaking change?

• Yes
• No

Type of change

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Documentation update (improves or adds clarity to existing documentation)
• Performance (kernel tuning, graph building, anything related to performance)
• Other (chores, tests, code style improvements etc.)

Testing instructions

1. pnpm --filter runntime exec playwright install chromium (once per machine)
2. pnpm --filter runntime test

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes generate no new warnings

[xxpopielxx]

This stack branches from before #58, which added trim() to the pool, so it needs a rebase from #60 up (add/add conflicts in bufferPool.test.ts and eval.gpu.test.ts, content conflicts in bufferPool.ts, eval.ts, replayCache.ts).

One thing to fix during the rebase: made keeps every buffer trim() destroys, so it grows by one set per input length forever. Could the pool track only the buffers in use instead (an inUse set: add on acquire, delete on release), and have dispose() destroy free plus inUse? Then trim() needs no change and each buffer sits in exactly one place. Plus a test: trim then dispose destroys each buffer once.

[xxpopielxx]

A captured executor stays frozen after dispose, so it can neither replay nor eval. Reset frozen here too, or note that a captured executor is done after dispose?