fix(proxy): use undici's own fetch (real fix for proxy 502 / UND_ERR_INVALID_ARG)

[twilson63]

Root cause (the real one)

The proxy passed an npm-undici Agent as the dispatcher to Node's built-in global fetch. Built-in fetch validates the dispatcher against its own bundled undici's Dispatcher class. When the npm undici version differs from Node's bundled undici, the Agent is a different class and is rejected with UND_ERR_INVALID_ARG — before any of our lookup/connector code runs.

This explains everything we saw:

• Worked locally (local Node's bundled undici ≈ npm undici 6.26.0).
• fix(proxy): handle both undici lookup signatures (proxy 502 regression) #42 (handle both lookup forms) and fix(proxy): pin SSRF connection via connector override (fixes proxy 502) #43 (connector override) both produced the identical UND_ERR_INVALID_ARG, because the failure happens at dispatcher validation, upstream of that code.

Fix

Call undici's own fetch (import { fetch as undiciFetch } from 'undici') so the dispatcher and fetch come from the same undici instance. One line of behavior change; SSRF validation and connector-based IP pinning are unchanged.

Why this is verified, unlike the prior two

proxy.test.ts doesn't mock fetch — it only covers validation/SSRF/allowlist paths that return before the network call, so it never exercised a real proxied request (which is why it stayed green through the regression). This fix was verified with a real end-to-end test: undici fetch + the pinned dispatcher + the exact response-handling path (body.getReader(), headers.forEach) → 200 for example.com/api.github.com; SSRF targets (169.254.169.254, 127.0.0.1, [::1], 10.0.0.1) still blocked.

• tsc --noEmit clean, npm run build clean, proxy.test.ts 52/52.

Follow-up (not in this PR)

Consider pinning the Node version in render.yaml/engines so the bundled-undici drift can't bite other global-fetch usage.

🤖 Generated with Claude Code