node:http: instantiating globalThis.Headers in an in-process http.Server + client program hangs the response pump

[proggeramlug]

Split out of #4965 (the setHeaders SIGSEGV, fixed separately). Once that crash is fixed, test-http-response-setheaders.js no longer segfaults but hangs — and the hang is not caused by setHeaders.

Minimal repro (no setHeaders involved)

const http = require('http');
const server = http.createServer((req, res) => {
  const headers = new globalThis.Headers({ foo: '1' }); // created, never used
  res.writeHead(200, { foo: '1', bar: '2' });
  res.end();
});
server.listen(0, () => {
  const req = http.get({ port: server.address().port }, (res) => {
    console.log('STATUS', res.statusCode);          // never prints
    res.on('end', () => server.close());
    res.resume();
  });
  req.on('error', (e) => console.error('client err', e.message));
});

• With the new globalThis.Headers(...) line → process hangs (exit 124 under timeout); the in-process http client's response callback never fires and res.end() on the server completes but the body/headers never reach the client.
• Remove that one line → STATUS 200 prints, process exits 0.

new globalThis.Headers(...) on its own (no server/client) is fine and exits cleanly — it's specifically the Headers + in-process http.Server + http client combination that wedges the response pump. Likely the fetch/http-client subsystem init triggered by Headers interferes with the http-server pump's event-loop draining.

Impact

Blocks test-http-response-setheaders.js from completing end-to-end even though the #4965 SIGSEGV is fixed and setHeaders now applies Headers/Map entries and throws the correct ERR_* codes.

Found on feat/size-optimize-npm worktree off v0.5.1171.