[Networking] Preserve guest HTTP requests through browser proxies

[brandonpayton]

Why

Browser guests need to make ordinary HTTP requests through a CORS proxy because a browser cannot open raw external TCP sockets. The previous paths did not share one request contract: the live shell did not configure the worker-side proxy directly, the development relay handled only GET, and the simpler fetch backend tried a direct browser fetch before using its proxy. In practice, a POST could lose its body or headers, and browser-default fetch behavior was not explicit about page credentials.

This blocks package registries and Git smart HTTP, but the fix belongs to the browser networking layer rather than to any one package manager.

What changes

• Give both browser HTTP backends one shared request policy. It preserves the guest method, body, and ordinary headers; removes browser-managed transport headers; and always uses credentials: "omit" with no referrer.
• Validate proxy configuration before the kernel worker starts. Production proxies must use HTTPS; HTTP is accepted only for loopback development. Relative URLs, embedded credentials, fragments, and malformed values fail clearly.
• Reserve the proxy-control header for the host. A guest Authorization header enables only authorization forwarding; a guest cannot ask the proxy to forward cookies or proxy credentials.
• Configure every live browser BrowserKernel from one environment-aware selector. Development uses the same-origin Vite relay, production keeps the configurable public default, and VITE_CORS_PROXY_URL remains the deployment override.
• Upgrade the development relay to carry GET and POST bodies and guest headers, cap request/response sizes, reject malformed or recursive targets, and remove browser cookies, origin/referrer context, forwarding headers, proxy credentials, and unsafe response headers.
• Document the browser/proxy trust boundary and keep Node's direct socket transport unchanged.

The request path is now:

guest HTTP client -> browser network backend -> configured CORS proxy -> target server

The service worker passes a request that already targets the configured proxy through unchanged, so it does not discard the method, body, or headers.

Validation

• cd host && npx vitest run test/cors-proxy.test.ts test/dev-cors-proxy.test.ts test/fetch-backend.test.ts test/browser-kernel.test.ts — 64 tests passed.
• npm --prefix host run build — ESM, CJS, and declarations built successfully (with the repository's existing CJS import.meta warnings).
• Loaded apps/browser-demos/vite.config.ts with tsx — passed.
• cd apps/browser-demos && KANDELO_PLAYWRIGHT_PORT=5417 npx playwright test test/browser-cors-proxy.spec.ts --project=chromium — 2 tests passed. This runs real guest GNU Wget GET and authenticated POST requests and verifies the exact body/headers plus cookie/referrer isolation.

The full host Vitest suite was also attempted in this sparse worktree: 1,573 tests passed, while 30 tests outside this change failed because their wasm64 sysroot, binary fixtures, repo-root JS dependency, or current generated PTY fixtures were unavailable or stale here. The focused networking tests above are clean.

[github-actions]

Phase B-1 matrix build status — pr-1057-staging

ABI v41. 6 built, 0 failed, 6 total.

Package	Arch	Status	Sha
kandelo-sdk	wasm32	built	5eb17e76
rootfs	wasm32	built	9035da2c
shell	wasm32	built	7a4f452e
lamp	wasm32	built	8b5bb8eb
node-vfs	wasm32	built	305c5959
wordpress	wasm32	built	7ea1941d

_{Auto-generated; replaced on each push. Raw data in the publish-status workflow artifact.}