test: handle plain HTTP proxy requests in the PROXY auth mock

[GiHoon1123]

Fixes #868.

Problem

The AUTH_TYPE=PROXY test suite fails on Node.js 26.5.0 with errors like:

SyntaxError: Unexpected token 'o', "okay" is not valid JSON

and, for tarball downloads:

TAR_BAD_ARCHIVE

Root cause

Node 26.5.0 bundles Undici 8.7.0, which changed how http:// (non-TLS) requests are proxied: instead of always tunneling through CONNECT, they're now sent directly to the proxy with an absolute-URI request line (GET http://example.com/... HTTP/1.1) — the standard way HTTP proxying works for plain HTTP.

The test's mock proxy server (tests/_registryServer.mjs) only ever implemented the CONNECT path (for tunneling) and unconditionally replied "okay" to any other request it received. Once Undici started sending plain proxied HTTP requests for the mock registry, Corepack tried to parse that "okay" body as registry JSON or as a package tarball, producing the errors above.

Fix

Parse the absolute-URI request line with new URL(req.url). If it targets the test's mock registry host, rewrite req.url to a relative path and forward the request into the existing mock registry server's own request handler via server.emit('request', req, res) — reusing its logic instead of duplicating it — rather than replying with the "okay" stub. Anything else gets a 404, matching the existing CONNECT handler's behavior of rejecting requests to any other host. The CONNECT handling itself is untouched, since it's still exercised (e.g. by older Node/Undici versions, or wherever a real TLS tunnel is needed).

Testing

• Reproduced the exact reported failure first: installed Node 26.5.0 (confirmed bundled process.versions.undici is 8.7.0, matching the issue), reverted this fix, and ran the PROXY test group — got the exact same TAR_BAD_ARCHIVE / JSON parse errors described in the issue, across all 4 tests in that group.
• Restored the fix — all 4 PROXY tests pass under Node 26.5.0.
• Ran the full tests/main.test.ts suite (114 tests) under both Node 22 and Node 26.5.0 — identical results on both (113 passed, 1 expected-fail via it.fails, unrelated to this change), confirming no regressions to the other AUTH_TYPE variants or other tests.

[MikeMcC399]

Thanks for submitting this PR to resolve the issue #868 I submitted! 👍🏻

I successfully ran the workflow in my fork, so I expect if a maintainer approves the workflow from your PR, it will also succeed and be ready to merge.