Webview resources fail silently with ERR_INSUFFICIENT_RESOURCES when a webview loads thousands of files (Linux renderer keeps default 1024 nofile soft limit)

## Summary

When an extension webview loads a very large number of resources concurrently, the webview service worker starts failing every request with `net::ERR_INSUFFICIENT_RESOURCES` ("The FetchEvent for resulted in a network error response: insufficient resources"). Nothing is surfaced to the user or the extension — the webview just never finishes booting. The underlying cause is that on Linux the **renderer process keeps the desktop session's default soft file-descriptor limit (1024)**, while VS Code's main/utility processes raise theirs to the hard limit.

Real-world impact: the OpenAI Codex extension (`openai.chatgpt`) currently ships ~4,900 webview asset chunks and requests thousands of them in a burst at startup. On any Linux desktop with the default `nofile` soft limit of 1024 its sidebar is permanently stuck on a splash screen with no error anywhere. Full investigation with evidence: https://github.com/openai/codex/issues/26131#issuecomment-4933937080 (several long-open "sidebar stuck on spinner" issues over there trace back to this).

## Environment

- VS Code 1.128.0 (deb), Ubuntu 26.04, default desktop session limits (`ulimit -n` soft 1024 / hard 524288)

Observed process limits (`/proc//limits`, `Max open files`):

| process | soft | hard |
|---|---|---|
| main | 524288 | 524288 |
| utility (network / extension host) | 524288 | 524288 |
| gpu-process | 16384 | 524288 |
| **zygote / renderer (hosts webviews + webview service worker)** | **1024** | 524288 |

## Steps to reproduce

1. Linux desktop with default soft `nofile` = 1024 (most distros)
2. Install an extension whose webview loads thousands of module chunks (e.g. `openai.chatgpt` 26.x)
3. Open the extension's webview view

**Result:** DevTools console of the webview shows hundreds of `The FetchEvent for "" resulted in a network error response: insufficient resources.` followed by `net::ERR_FAILED` for every chunk; the webview never boots. The workbench console also logs listener LEAK warnings from `fileService.ts` `readFileStream` (hundreds of concurrent streams created by `webviewElement.ts` `loadResource`).

**Workaround that fully fixes it:** quit VS Code and launch with `ulimit -n 65536 && code` (or raise `DefaultLimitNOFILE` for the systemd user session).

## Expected behavior / suggestions

Any of these would prevent the silent failure:

1. **Raise the renderer soft fd limit to the hard limit** at startup, as is already done for the main/utility processes (Chromium keeps renderers at the inherited soft limit, but VS Code's webview resource loading routes real file I/O through them, which breaks Chromium's "renderers don't need many fds" assumption).
2. **Queue/throttle webview resource loading** (`webviewElement.ts` `loadResource` / the `vscode-webview` service worker) so that an arbitrary number of requested resources never exceeds a safe number of in-flight streams. This would also fix the `fileService` listener-leak warnings.
3. **Surface the failure**: when webview resource loads fail with `ERR_INSUFFICIENT_RESOURCES`, report it to the extension and/or the user instead of failing silently — this failure mode currently presents as "extension webview hangs forever" and is effectively undiagnosable for end users (multiple months-old issue threads in extension repos).

Happy to provide more logs or test a patched build.