fix: cancel extension fetch proxy requests

[JustYannicc]

What changed

• Moved the renderer extension fetch proxy into a small extension-fetch-bridge helper that generates a request ID for every proxied HTTP(S) fetch.
• Wired init.signal and Request.signal aborts to electron.cancelHttpRequest(requestId) and removed abort listeners on every terminal proxied path.
• Preserved native fetch fallback for non-HTTP URLs and IPC-unsupported bodies, and kept the binary download response path intact.
• Replaced sync zlib response decoding in the main HTTP proxy with async zlib decoding and a single-settle guard for cancel, timeout, socket error, redirect, and decode completion races.
• Added targeted tests for abort propagation/listener cleanup and async compressed response decoding.

Why

Extension-level fetch() requests could be abandoned after an extension unmounted or aborted, but the bridge did not pass requestId, so main-process sockets/work stayed alive until natural completion. Large compressed proxied responses also decoded synchronously on the Electron main thread, creating a cross-extension stall risk.

Compatibility impact

HTTP(S) extension fetch responses keep the same Response construction, headers, status fields, URL override, native fallback behavior, and binary download handling. Aborted proxied fetches now reject with AbortError, matching platform fetch semantics, while non-HTTP and unsupported body requests continue through native fetch.

How tested

• node --test scripts/test-extension-fetch-proxy-abort.mjs scripts/test-http-response-decode-async.mjs scripts/test-use-fetch-stale-runs.mjs
• pnpm run build:main
• pnpm run typecheck:renderer
• pnpm run build:renderer
• Codex LSP diagnostics on src/renderer/src/extension-fetch-bridge.ts, src/renderer/src/ExtensionView.tsx, src/main/http-response-decode.ts, and src/main/main.ts: no diagnostics found.

Performance evidence

Abort/request cleanup before: extension fetch IPC sent { url, method, headers, body } with no requestId, so http-request-cancel could not reach activeHttpRequests; abort listeners were not part of the bridge.

Abort/request cleanup after: scripts/test-extension-fetch-proxy-abort.mjs verifies each proxied fetch sends an extensionFetch: request ID, duplicate aborts emit exactly one cancel for that ID, the abort listener count goes 1 -> 0 after completion, and the success path finishes with zero abort listeners and no cancel calls. Existing stale-run coverage in scripts/test-use-fetch-stale-runs.mjs still passes for request replacement/unmount cancellation patterns.

Decompression before: main proxy used brotliDecompressSync, gunzipSync, and inflateSync before converting full response bodies to UTF-8.

Decompression after: src/main/http-response-decode.ts uses async zlib APIs only; the deterministic gzip fixture test confirmed decoded text compatibility and logged event-loop timer evidence for a 9,800,000 byte fixture. Test run evidence: sync baseline delayed the timer by 24.78 ms while async decode allowed it at 1.466 ms; repeat validation after the type fix logged 4.612 ms sync vs 2.802 ms async.

Stack validation

Started from detached base 206eab8280a2eb91a57e4e74ea6df99e45a55cb4 and created codex/perf-wave4-extension-fetch-proxy. No coordinator markdown, playbooks, prompts, or generated lockfiles are included.

Replaces

Replaces the perf wave 4 coordinator finding for extension fetch proxy abort propagation and compressed response main-thread stall risk.

[JustYannicc]

Closing in favor of #601, which fully replaces this granular PR in the wave4 runtime/main consolidation. Literal validation now passes with /opt/homebrew/opt/node@22/bin/npm run build:main, and #601 is ready for review.