fix(test): settle watch step on the last build to avoid stale transition rebuilds

[stormslowly]

Why

watchCases/side-effects/issue-7400 > should compile step 1 is flaky on WASM CI (example): step 1 runs a bundle that still asserts step 0's expect(WATCH_STEP).toEqual("0") while WATCH_STEP is already "1" → expected '1' to deeply equal '0'.

Root cause (reproduced + instrumented). The watch harness synchronizes step transitions with emitter.once(Build) — it takes the first Build after copyDiff. Under heavy concurrent compilation load (WASM is slower, so the window is wider), watchpack emits an extra rebuild during the step transition that still carries the previous step's content; once captures that stale rebuild, and the runner executes the wrong bundle. The real, copyDiff-triggered rebuild lands just after.

Evidence from an instrumented reproduction: stale runs had exactly 3 builds for the step (vs 2 when healthy); the captured build's hash carried step-0 content while the correct build landed later; reproduced 46/500 under amplified load, 0/150 without. Native is always clean because the transition rebuild drains before the next step.

This is harness fragility, not a watcher bug — the compiler rebuilds correctly; once(Build) just cannot tell the step's rebuild from an extra one.

What

Wait for the last build the step settles on instead of the first: keep resetting a settleWindow (> the watcher aggregateTimeout) on every Build and resolve once no new build has arrived. The final build always reflects the current sources, so a stale transition rebuild is superseded by the real one. The listener is armed before copyDiff, so a rebuild a step legitimately relies on that is already pending (e.g. the change-event/metadata case, whose plugin touches a file to trigger a rebuild) is still captured.

Change is confined to createWatchStepProcessor. Validated green across Linux / macOS / Windows / WASM, including change-event/metadata, with STALE=0 under both moderate and extreme load in the instrumented reproduction.

[github-actions]

📦 Binary Size-limit

Comparing cd1c043 to fix(esm_library): preserve static source-phase external bindings (#14674) by Elecmonkey

🎉 Size decreased by 164.00KB from 66.74MB to 66.58MB (⬇️0.24%)

[codspeed-hq]

Merging this PR will degrade performance by 2.17%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

❌ 1 regressed benchmark
✅ 42 untouched benchmarks
⏩ 47 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	rust@split_chunks	2.1 ms	2.2 ms	-2.17%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing test/repro-wasm-watch-issue7400-flaky (b881444) with main (a0d0e77)}

Footnotes

1. 47 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩