bug(runtime): buildProxyDispatcher silently dropped to undici 8's forward-by-default HTTP proxy semantics (pin proxyTunnel: true) #6005

What happened

buildProxyDispatcher (packages/runtime/src/network/proxy-dispatcher.ts:47) creates its ProxyAgent without proxyTunnel, so since the undici 7 → 8 major jump (#1247, undici 8.7.0; now 8.11.2) plain-HTTP targets are forwarded to the proxy as absolute-form requests instead of being CONNECT-tunneled. Undici 7 tunneled every request; undici 8 only tunnels non-http: protocols unless proxyTunnel: true is passed explicitly (packages/runtime/node_modules/undici/lib/dispatcher/proxy-agent.js):

function shouldProxyTunnel (requestProtocol, proxyTunnel) {
  return proxyTunnel === true || requestProtocol !== 'http:'
}

Minimal offline probe (fake proxy that records what arrives, then tunnels CONNECT to a local target), against the installed undici 8.11.2:

[default (no proxyTunnel)] body=proxy-forward-ok   proxy saw: GET http://127.0.0.1:<target>/models
[proxyTunnel:true]         body=target-ok          proxy saw: CONNECT 127.0.0.1:<target>

Why it matters

• The dispatcher's clientFactory composition exists to keep CONNECT-tunnel sockets cancellable ("CONNECT transfers the tunnel out of the proxy pool before target TLS settles"). Under forward semantics that upgrade hook never engages for http: targets, so the abort/cleanup contract silently does not apply to plain-HTTP proxying.
• CONNECT-only proxies (or proxies whose forward path misbehaves) break for http: targets. hqhq1025's P2 on ci(perf): retire the broken transcript data-plane benchmark #5805 (2026-09-29) verified a hang of the existing closed successful connections ... (http) suite shape against real undici majors and asked to "preserve the previous HTTP behavior and add a focused proxy regression test".
• Current success-path coverage passes by accident of the forward semantics: the fake proxy in scoped-fetch-transport.test.ts answers any request with 200 proxy-ok, so an absolute-form forward never proves the proxy chain reached a real target.

History / intent

• #5043 (2026-09-27) already asserts the tunnel wire format elsewhere: startStalledProxy requires CONNECT provider.invalid:443 for its http stages, and startConnectProxy accepts both CONNECT-then-origin-form and absolute-form. Tunneling is the codebase's working assumption; I found no decision adopting forward semantics.
• This came out of the dependency-graph review of ci(perf): retire the broken transcript data-plane benchmark #5805; the finding was confirmed there to belong on main, not that PR.

Proposal

Pass proxyTunnel: true explicitly in buildProxyDispatcher (restoring the undici 7 behavior for all targets) and add a focused regression test asserting that an http:// target through buildProxyDispatcher reaches the proxy as CONNECT and gets its response from the tunneled target.