fix(perry-ext-fastify): #747 + #746 — event_loop + wait_for_promise pump stdlib

[proggeramlug]

Summary

• perry-ext-fastify::event_loop doesn't pump stdlib — perry-ext-{ws,net,http} events stranded after app.listen() #747 (root fix). perry-ext-fastify's event_loop was missing the js_run_stdlib_pump() call that the original perry-stdlib::fastify version (crates/perry-stdlib/src/fastify/server.rs:270-289) has had all along. The port in v0.5.572 (commit 97e80d3) dropped it. Any program combining fastify with a perry-ext-* wrapper (ws, net, http, fetch) had its listener callbacks stranded the moment app.listen() entered its loop — events accumulated on tokio workers but the JS main thread never drained the per-wrapper queues.
• WebSocketServer.on() callbacks never fire on incoming connections (regression v0.5.491–v0.5.700+) #746 (same root cause in the realistic use case). The user's hub binary imports both ws and fastify; the symptom they filed against the WS surface ("wss.on('connection', cb) never fires on v0.5.700–v0.5.892") was the same defect surfacing through the fastify event loop. The pure-WS-only minimal repro from WebSocketServer.on() callbacks never fire on incoming connections (regression v0.5.491–v0.5.700+) #746 already passes on macOS at HEAD via the codegen-emitted main event loop's existing pump call, so closing perry-ext-fastify::event_loop doesn't pump stdlib — perry-ext-{ws,net,http} events stranded after app.listen() #747 closes WebSocketServer.on() callbacks never fire on incoming connections (regression v0.5.491–v0.5.700+) #746 in practice for the realistic hub scenario.
• Native route returns body 0 + HTTP 200 after sequence of @perryts/mysql writes; first INSERT commits, rest silently no-op, explicit return dropped #748 (investigated, not closed). Initial hypothesis was that the same wait_for_promise omission caused @perryts/mysql's await pool.exec(...) chain to stall after the first INSERT. Disproven — a perry-ext-bcrypt chain (same queue_promise_resolution mechanism) works fine without the wait_for_promise pump because the codegen-emitted await loop at crates/perry-codegen/src/expr.rs:9500 already pumps stdlib on every iteration. Native route returns body 0 + HTTP 200 after sequence of @perryts/mysql writes; first INSERT commits, rest silently no-op, explicit return dropped #748 stays open.

Three edits in crates/perry-ext-fastify/src/server.rs:

1. extern "C" block: declare js_run_stdlib_pump (defined in crates/perry-runtime/src/lib.rs:177, dispatches through the STDLIB_PUMP_FN AtomicPtr that perry-stdlib registers at startup).
2. event_loop: call it ahead of js_promise_run_microtasks(), matching perry-stdlib's order.
3. wait_for_promise: same call inside the per-iteration body, for parity with perry-stdlib's wait_for_promise at crates/perry-stdlib/src/fastify/server.rs:432 — defense-in-depth for the rare case of an externally-resolved Promise returned by a route handler without an inner await chain.

Test plan

• Combined fastify + ws repro reproduces the bug without the fix — /tmp/test_746_with_fastify.ts (Fastify().get(...).listen({port: 18905}) alongside new WebSocketServer({port: 18906})): before the fix, [wss listening] never printed and [wss connection fired] never printed; after the fix, both fire on the next event-loop tick.
• Pure-WS minimal repro from WebSocketServer.on() callbacks never fire on incoming connections (regression v0.5.491–v0.5.700+) #746 — /tmp/test_746_exact.ts matches the issue body verbatim. Passes on macOS at HEAD (verified before + after the fix).
• Multi-await fastify handler — /tmp/test_748_fastify_async.ts with 3× await Promise.resolve(N) + reply.code(201) returns {a:11,b:22,c:33,sum:66,stage:4} HTTP 201 in 4 ms.
• Multi-await perry-ext-bcrypt chain in a fastify handler — /tmp/test_748_bcrypt.ts with 2× bcrypt.hash + bcrypt.compare returns {h1_len:60,h2_len:60,ok:1,hashes_differ:true} HTTP 201 in 4 ms. This is the same async-await + perry-ext-* + fastify shape from Native route returns body 0 + HTTP 200 after sequence of @perryts/mysql writes; first INSERT commits, rest silently no-op, explicit return dropped #748 and works correctly (which is what disproved the wait_for_promise hypothesis for Native route returns body 0 + HTTP 200 after sequence of @perryts/mysql writes; first INSERT commits, rest silently no-op, explicit return dropped #748).
• cargo test --release -p perry-ext-fastify — 10 passed.
• cargo test --release --workspace --exclude perry-ui-{ios,tvos,watchos,visionos,android,windows,gtk4} — exit 0.
• cargo build --release -p perry-ext-fastify -p perry — clean.
• Linux verification of the pure-WS minimal repro — left as a follow-up. The defect described in WebSocketServer.on() callbacks never fire on incoming connections (regression v0.5.491–v0.5.700+) #746's body should be fully covered for the user's hub via the fastify+ws path; if the pure-WS Linux symptom persists post-fix, it needs separate diagnosis (Linux-specific symbol resolution? something else linking through perry-ext-fastify?).
• Native route returns body 0 + HTTP 200 after sequence of @perryts/mysql writes; first INSERT commits, rest silently no-op, explicit return dropped #748 root cause investigation — needs a real @perryts/mysql + MySQL setup to reproduce. Not in this PR.