A fix for a flake from today's list: nodejs/reliability#1597.

Can't reproduce the flake locally directly, but I can with a small delay on the server stream response to simulate the very plausible IO delay on the response. Flake 100% reproduces with a setTimeout into the server stream handler at the top:

server.on('stream', (stream) => {
  stream.on('error', () => {}); // We need errors handlers just for the repro
  setTimeout(() => { // Delay longer than the setInterval below
    try {
      stream.respond();
      stream.end('ok');
    } catch {}
  }, 100);
});

This fails every time, as in the flake example in https://github.com/nodejs/reliability/blob/main/reports/2026-07-10.md:

Error [ERR_HTTP2_TOO_MANY_ORIGINS]: The server sent more ORIGIN frames than the allowed number of -0
    at Http2Session.onOrigin (node:internal/http2/core:783:23)
Emitted 'error' event on ClientHttp2Stream instance at:
    at emitErrorNT (node:internal/streams/destroy:170:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
  code: 'ERR_HTTP2_TOO_MANY_ORIGINS'
}

I'll do a stress test as well and see if I can confirm the fix directly.

Flake explanation:

• The server runs a 10ms interval on every session which sends 10 origins
• The test tries different <10 max origin limits, which will all fail
• The test also sends a request
• When the origins are rejected, the session is destroyed
• All open request streams will also be destroyed when the session is destroyed
• This creates a race:
  • If the request completes before the interval then the test passes (request finishes clean, session destroyed as expected)
  • If the request is still open when the interval fires and destroys the session, the request fails and emits an unhandled error => flake.

This PR fixes that by dropping the request (and server handler) completely from all tests here (the immediate flake, as well as the others). They aren't necessary - I think they exist because this was copied from test-http2-origin, which does actually use the request flow.

These tests though operate purely on just the session directly (server session handler triggers the interval, client session emits the error). The requests were ignored and the server handler did nothing. Dropping the requests completely simplifies the test and kills the race.

Would be good to get confirmation of that from @mcollina, since this was added as a security fix (https://github.com/nodejs-private/node-private/pull/855) which I can't see but I'm fairly confident.