Restore Connect thread-loading speedup, without the gzip corruption

[SawyerHood]

Restores #909 (reverted in 17d652c) and fixes the response corruption that forced the revert.

The corruption

#909 lets the tunnel client forward the origin's compressed bytes verbatim. The gate then rebuilt those bytes into new Response objects under workerd's default encodeBody: "automatic", which means "this body is identity and I own the encoding" — so workerd dropped content-encoding and shipped gzip bytes labelled text/html. Browsers rendered raw gzip.

Two sites relayed pre-encoded bodies that way, and the correct fix is asymmetric:

Site	Body it wraps	Encoding
tunnel-do.ts resp-head	raw origin bytes from tunnel frames	manual — was corrupt
cache.ts hit	Cache API stores bytes still compressed	manual — was corrupt
cache.ts miss	workerd content-decodes a subrequest body as the gate reads it	automatic — already correct

Marking the miss path manual (the symmetric-looking fix) actively breaks it: it advertises gzip over plaintext and clients fail with Z_DATA_ERROR. The regression test catches that.

Regression test

apps/connect/src/response-encoding.test.ts drives the real TunnelDO and real serveWithCache inside workerd (miniflare), with a fake tunnel client relaying gzip frames over a real WebSocket. Node's Response ignores encodeBody, so a Node-only test would pass with or without this fix.

Mutation-checked: reverting the tunnel-do.ts call site fails 4 tests, reverting the cache.ts hit path fails 1. Two control routes pin workerd's default behaviour so the tests document the bug rather than merely guarding it.

Verification on real Cloudflare

Deployed to staging (bb-connect-staging, version 0946eaab, sawyer.vibecodethis.site). Because the tunnelled path needs a client + owner session, the end-to-end check ran against a throwaway workers.dev probe running this same TunnelDO + cache.ts, driven by the real TunnelSession client in front of the real built bb app (383 precompressed .gz assets, served as apps/server does). Probe deleted afterwards.

• index.html: gzip-only client got 1509 raw bytes (1f8b0800) gunzipping to exactly 4255 bytes of real HTML; browser-style clients got it transcoded to zstd by the edge — which the edge can only do if it correctly understands the body as encoded.
• 342 KB app bundle, miss → hit → hit: x-bb-cache: miss/hit plus cf-cache-status: HIT, every response gunzipping to sha256 18cb8f3a…, byte-identical to the origin file.
• Legacy control at the edge reproduces the production symptom: content-encoding dropped, edge zstd-wraps the raw gzip, browser renders ^_M-^K^H… as text/html.
• Accept-Encoding: identity: correct 4255 plain bytes, no encoding header.
• Identity bodies measured through both paths are byte-identical (19984 → 4882 gzip, zstd for browser-style), so manual does not suppress edge compression for uncompressed origins — port shares and pre-Speed up thread loading over Connect #909 clients keep it.

Compatibility

Old client → new gate is safe: a pre-#909 client strips accept-encoding and drops content-encoding from resp-head, so its bodies are identity with no encoding header and manual asserts nothing false.

The broken direction is new client → old gate, which is unchanged by this PR: prod's gate must ship this before any released client carries the reapplied #909. Merging this triggers deploy-connect.yml, which deploys the prod gate — the correct order.

HOST_DAEMON_PROTOCOL_VERSION not bumped (stays 68): worker-only change, no daemon command / session payload / WS message altered, tunnel frame format unchanged (PROTOCOL_VERSION stays 1).

Tests

• @bb/connect 88 ✅ + typecheck
• @bb/tunnel-client 6 ✅ + typecheck
• bb-plugin-connect 65 ✅
• @bb/app 28 focused (the four suites from Speed up thread loading over Connect #909) ✅ + typecheck

🤖 Generated with Claude Code