Web: webview service worker intermittently loses interception; requests escape to vscode-cdn.net via real DNS and the retry flood crashes the shared render process, freezing every same-site tab

## Environment

- VS Code Web 1.127.0, served via code-server (`1e6ed874e3138141a5636f6e0dbe8570aa6cd001`), in a Podman container behind Caddy (HTTPS/wss)
- Browser: Brave 150.1.92.139 (Chromium 150, Wayland), Pop!_OS Linux
- Trigger extension: openai.chatgpt (Codex) 26.5707.31428 / 26.5707.41301. It is the heaviest webview in this setup and auto-opens its panel in every window.
- Filed here on the code-server maintainer's suggestion (coder/code-server#7892). The failing path is VS Code web's webview service worker, not the wrapper.

## Summary

Intermittently, and apparently as a race, webview resource requests are not intercepted by the webview service worker. They instead go to the virtual hostname `vscode-cdn.net` through real DNS and fail with `net::ERR_NAME_NOT_RESOLVED`. The failed requests then retry in a tight loop inside the renderer. The per-process pending-request pool exhausts, so every fetch starts failing with `FetchEvent … resulted in a network error response: insufficient resources`, and the render process crashes ("Render process gone"). Every same-site tab shares that render process, so all open tabs to the deployment freeze at the same moment.

## Steps to reproduce

1. Enable the Codex extension so its panel webview auto-opens in each window.
2. Open roughly 6 concurrent tabs to the same host in one Chromium profile. Same-site tabs share a render process.
3. On the 6th tab the renderer dies and all tabs freeze. DevTools on any of them reports "Debugging connection was closed. Reason: Render process gone."

It also reproduces on its own with fewer long-lived tabs after several hours, and enabling the extension in a live window has frozen all tabs instantly. With the extension disabled the same workload is stable indefinitely. We verified that A/B in both directions.

## Evidence

- Browser-process netlog (`chrome://net-export`) spanning a deterministic crash. It shows real DNS lookups for `main.vscode-cdn.net` failing `ERR_NAME_NOT_RESOLVED` at the crash moment, and 6 webview `pre/index.html` spinups in the ~30 s before it. There is no network-service-level flood and zero `ERR_INSUFFICIENT_RESOURCES` in the netlog, so the exhaustion is internal to the renderer's fetch/SW layer. Netlog available on request, with cookies and headers scrubbed.
- Frozen-tab console: a storm of `FetchEvent for resulted in a network error response: insufficient resources` (cf. GoogleChrome/workbox#2528).
- A capture during the degradation phase: webview assets failing to `vscode-resource.vscode-cdn.net` with `ERR_NAME_NOT_RESOLVED`, and the `loadResource` listener count climbing from 175 to 615+.
- A healthy-baseline HAR for contrast: zero requests to vscode-cdn.net, with the service worker intercepting normally.
- Server logs are clean throughout. The failure is entirely client-side.

## Related reports

These look like the same exhaustion reached by different paths:

- #326500 (desktop, secondary windows): the `loadResource` reads stall, the service worker still intercepts, and its FetchEvents exhaust into `ERR_FAILED`. Same extension and the same listener-pileup signature. In our web case the service worker loses interception and the renderer crashes instead.
- coder/code-server#7892 (where this originated), plus #7850 and #7890: independent code-server users hitting the same freeze.
- Extension-side companions, covering the unbounded retry and the module-preload fan-out: openai/codex#32475 and openai/codex#34103.

## Questions and a suggested direction

- Is there a known race where the webview service worker loses its registration or claim (or is evicted in long-lived tabs), so resource requests fall through to the `vscode-cdn.net` default?
- The fix #326500 suggests would help here too: serve webview resources through a bounded-concurrency queue and cap retries, so both failure modes degrade to slower throughput instead of a dead process. On top of that, re-registering or re-claiming the service worker (or at least surfacing an error) once webview requests start escaping to real DNS would stop the renderer crash.

## Does this reproduce in native VS Code?

No. The browser webview service worker and the shared same-site render process only exist in web deployments. We have not tried a `code serve-web` or Codespaces repro yet, and can prioritize that if it would help triage.