fix(h2): destroy aborted stream synchronously instead of via setImmediate

[staylor]

Follow-up to #5462.

#5462 fixed a leak where an aborted HTTP/2 request left teardown to the stream's async 'close' event, which can fail to fire on a busy, long-lived multiplexed session — pinning the native Http2Stream and the request graph it references. It did so by destroying the stream after close(), but deferred the destroy behind a setImmediate so the RST_STREAM frame queued by close() is written first.

That deferral reintroduces the same leak under a different trigger. setImmediate callbacks only run once the loop reaches the check phase, so while the event loop is stalled by a long synchronous task the deferred destroy never runs. Every stream aborted during the stall stays alive (plus the request graph each one pins), and abort churn — timeouts, cancellations — tends to spike precisely when the loop is busy. The result is an unbounded, positive-feedback leak until the process OOMs.

This was not hypothetical for us: a high-throughput fetch service (~100K req/s across the fleet) that periodically stalls its loop under bursty work saw memory roughly triple and the fleet enter a sustained OOMKilled crashloop immediately after taking stock 8.7.0 (which carries the setImmediate defer) in place of a local patch that destroyed synchronously. Details in #5558.

Change

• Destroy the stream synchronously after close() in the writeH2 abort path. close() has already queued the RST_STREAM frame on the native session, so it is still sent; teardown no longer depends on the event loop advancing.
• Tighten the 'Should destroy the h2 stream on abort' regression test to assert the stream is destroyed synchronously on abort (drops the waitFor poll), so a future re-deferral fails in CI instead of in production.

Testing

test/http2-dispatcher.js (all 18) plus http2-abort, http2-goaway, http2-destroy-after-failed-stream, http2-response-after-completion, http2-timeout, and http2-stream pass locally. eslint clean.

If there is a concrete RST_STREAM-ordering scenario the setImmediate was guarding against that isn't covered by the current tests, I'm happy to add a case for it — but in practice close(code) submits the frame to the native handle synchronously, so a subsequent destroy() still delivers it.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.44%. Comparing base (a360781) to head (2c1dca1).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5559      +/-   ##
==========================================
- Coverage   93.44%   93.44%   -0.01%     
==========================================
  Files         110      110              
  Lines       37434    37434              
==========================================
- Hits        34980    34979       -1     
- Misses       2454     2455       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

lgtm