Changes touching this path

• the runner major was the whole chain: sdk npm audit goes to zero, and 92/92 says the bump is safe (#951) Seven vulnerabilities, and they were not seven problems. `npm audit fix` cleared the two in-range ones (nanoid 3.3.16 -> 3.3.18, postcss 8.5.21 -> 8.5.26, a two-entry lockfile diff, package.json untouched) and the remaining five were one chain: esbuild <=0.24.2 through vite <=6.4.2 through vitest, four of the five being nothing but that dependency reported at each hop. So the decision was never five decisions. It was one: does the suite survive vitest? The ticket said decide it on evidence, so it was measured rather than argued. vitest 2.1.x -> 4.1.10 (two majors) baseline in the lane 58 passed | 34 skipped after the bump 58 passed | 34 skipped (identical) with the release binaries built so the behaviour suites can run: 9 files, 92 PASSED (92) npm audit 0 vulnerabilities tsc --noEmit clean Not an overrides pin, which is how site/ solved the same advisory in #916: there every declarer accepted the patched range, so the override violated no constraint. Here the patch is esbuild 0.25 and vite 6 asks for ^0.24.2, so an override would have forced a version outside a declared range and called it fixed. The runner bump keeps every constraint satisfied and leaves nothing pinned for the next person to re-read. The lockfile diff is large and it is one thing: vite 8 swaps the bundler, so esbuild and rollup leave entirely and rolldown arrives (38 added, 60 removed, 17 changed; 73 packages total, down from 95). Reviewed rather than absorbed (#894) — the only package.json change is `vitest ^2.1.8 -> ^4.1.10`. ⚠ Measured against a FRESH wasm core, deliberately: #914's stamp gate now refuses a stale one, and diagnosing a runner bump through a stale core is exactly the misdiagnosis that ticket exists to prevent. ec26fa25 · dbf3dbe6…

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.