node-fetch: local HTTP request fails with "Invalid response handle"

[proggeramlug]

Summary

node-fetch@3.3.2, compiled from its public package entry on current main (47ade47327), gets through construction of its derived Headers Proxy but fails during a GET against a local node:http server:

Error: Invalid response handle
    at new __AnonShape_105fb05143d2f2d2 (<anonymous>)

This is the current blocker found while re-testing #10809. The original Must call super constructor failure does not reproduce on current main; why the earlier and current runs differ is not yet known.

Reproduction shape

1. Install node-fetch@3.3.2.
2. Add node-fetch to perry.compilePackages.
3. Start a local server with node:http.
4. Import the public default export from node-fetch and perform a GET against that server.
5. Compile and run the fixture with Perry.

The source graph contains 22 compiled modules across node-fetch, data-uri-to-buffer, fetch-blob, formdata-polyfill, node-domexception, and web-streams-polyfill. No partial-codegen flag or internal package import is used.

Expected

The request completes and exposes the local server response, as under Node.

Actual

The request reaches a separate HTTP integration failure with Error: Invalid response handle.

Provenance

Split from #10809 so the resolved/non-reproducible constructor symptom and the current node-fetch blocker can be tracked independently. See the re-test details.

[proggeramlug]

Dependency correction: on a coherent pristine-main build, #10809 reproduces and blocks this failure. The Invalid response handle result was observed with the pending #10886 runtime changes present. Investigation of this issue is therefore being performed as a stacked change on #10886.

[proggeramlug]

Fixed in v0.5.1633 (merge train 253, 0fa3915293) by #10900 — fix(hir): honor lexical fetch bindings. A call through a lexical fetch binding (including node-fetch's default export) was being treated as the global Web Fetch API, routing the userland response through native response-handle methods — hence Invalid response handle. Verified by running a_lexical_fetch_result_is_not_registered_as_a_native_response (passes), and the full perry-hir suite is 471/0.