fix(runtime): #1114 — spin-throttle bypassed by NOTIFIED fast-path reset

[proggeramlug]

Summary

The #1114 spin throttle in js_wait_for_event is structurally bypassed when NOTIFIED flips on every iteration. The fast-path return called spin_streak_reset(), and js_notify_main_thread fires from inside every promise resolve / async-step chain / net-event push — so a tight async tick that does any internal promise work prevents the streak counter from ever accumulating.

This PR makes the streak survive across NOTIFIED fast-path returns; only an actual cvar.wait_timeout sleep resets it. The designed sub-µs hot path is preserved (calls that never hit budget_ms == 0 never grow the streak), but a true "timer pinned in the past + hot internal notifies" wedge now accumulates streak and the throttle fires.

Repro / regression test

Added notified_interleave_does_not_mask_wedge in crates/perry-runtime/src/event_pump.rs. The test:

1. Pins a js_set_timeout(0.0) so every call sees budget_ms == 0.
2. Alternates js_notify_main_thread() + js_wait_for_event() past SPIN_THROTTLE_AFTER.
3. Measures one further budget-0 call and asserts it's ≥700 µs.

I verified the test catches the bug: re-applying just the offending spin_streak_reset() line on the fast path made the test fail with best post-threshold call 125ns — the throttle is bypassed by the notify fast-path, exactly the #1114 wedge.

All 5 existing event_pump tests still pass.

Honest caveat

This fixes one of the structural defects discussed on #1114, but shop-admin's specific JobLoop reproduction is not fully resolved by this change. After installing the patched perry, the first request to /healthz returns 200 in ~100 ms; subsequent requests time out, with the server alive at ~95 % CPU. The earlier madvise-dominant profile is gone — sample now shows __psynch_cvwait dominant, suggesting the main event loop is no longer the source. Best guess for what's left: the @perryts/mysql tx() connection-release path is leaving state behind that starves the hyper accept-loop, or a tokio scheduler interaction with perry's event pump. That's a deeper investigation I haven't completed.

This is still worth landing on its own merits — the throttle is supposed to be a wedge backstop and it was completely bypassed for the most common wedge shape (interval timer + async work). With this fix it actually backs off as designed.

I'll keep #1114 open with both this PR linked and a note about the remaining residual.

Test plan

• cargo test -p perry-runtime --release event_pump:: — all 5 pass
• Toggled the buggy line back on, ran just the new test — failed as expected with a sub-µs post-threshold call
• Toggled fix back in — new test passes (≥700 µs measured)
• Built v0.5.1017 and reinstalled, re-ran shop-admin's e2e — confirms (a) the boot-time [5/7] WS broker registration still works (FastifyInstance.server returns a number — blocks ws/http2 upgrade piggybacking #1113 stays fixed), (b) the throttle fix alone doesn't close the shop-admin wedge (next investigation), (c) the sample profile signature changed from madvise-dominant to cvwait-dominant, consistent with the runtime no longer thrashing on allocations.

Tested against the JobLoop in ~/projects/skelpo-shop-admin/server/jobs/loop.ts, which is a 1Hz setInterval that awaits claimJobs(workerId, BATCH_SIZE) via @perryts/mysql.