fix(relay): keep bulk streaming from blocking client requests

Negotiate downstream delivery credit and schedule response streams fairly before encryption. Bound queued output, preserve deltas and WebSocket close ordering, and retain legacy peer compatibility.

Validated with 81 relay tests, workspace type-check and lint, web build and mobile assets, and slow-link tests through the production relay. Confirmed on LTE by the maintainer.

packages/web/server/lib/relay/DOCUMENTATION.md

@@ -25,6 +25,7 @@ Host side (`packages/web/server/lib/relay/`):
 - `host-client.js` — the long-lived connection manager: one outbound control connection to the relay, a per-client data connection for each connected device, reconnect/backoff, and the E2EE responder handshake per connection.
 - `host-lock.js` — the per-machine host claim. Every local instance sharing the data dir shares the relay identity (same serverId), so concurrent relay hosts evict each other at the relay worker (`4001: Control replaced`) and paired devices land on whichever local process won last. The claim file (`<data-dir>/relay-host.lock`, `{ pid }`) makes this deterministic: `service.js` only starts the host when no LIVE process holds the claim (stale claims from dead pids are ignored), goes to `standby` otherwise, and a 30s watcher both takes over when the claimant dies and stands down when another process claims. A standby watcher waits a 2-minute grace after the claim frees before taking over, so a cleanly restarting host (app update/relaunch) — which reclaims at boot with no wait — always wins the restart window over a bystander instance. Explicit user intent — creating a pairing link or hitting `/relay/enable` — force-claims; the previous holder's watcher sees the takeover and backs off instead of fighting. Instances created with `allowPassiveHost: false` (dev servers via `OPENCHAMBER_RELAY_HOST=off`, the Electron dev shell via `OPENCHAMBER_ELECTRON_DEV`; `OPENCHAMBER_RELAY_HOST=on` overrides) never start the host passively at all — boot, demand reconcile, and watcher takeover leave them in `standby`; only explicit enable/pairing hosts there. The claim is cooperative (the relay worker still enforces the single host slot); it only decides which process keeps retrying.
 - `tunnel-host.js` — the per-connection dispatcher: decrypts tunnel frames and forwards HTTP/SSE/WS to the local server over loopback, then streams responses back. Enforces a path allowlist and never injects credentials.
+- `downstream-scheduler.js` owns end-client delivery credit and round-robin transmission across response streams. It selects plaintext frames before encryption.
 - `e2ee.js`, `tunnel-codec.js` — host-side (JS) mirrors of the shared crypto and framing (see "Two implementations" below).
 
 Client side (`packages/ui/src/lib/relay/`):
@@ -47,6 +48,53 @@ The host dispatcher restricts tunneled traffic to explicit path allowlists (one
 
 Request bodies crossing the tunnel are buffered on the host and forwarded to loopback only once the client's `StreamEnd` frame arrives (bodies above ~512 KB stream live instead). A body whose frames were lost in transit therefore never reaches the loopback server as an empty/truncated chunked body — the host aborts the stream and the client sees an ambiguous transport failure it can retry, instead of the loopback server's bare `400` ("Failed to send message (400)" from the mobile app).
 
+## Downstream flow control
+
+`hello` and `ready` negotiate `flowControl: true` independently of `batch`.
+When either peer omits the flag, the host keeps the legacy transmission path.
+This capability controls host-to-client traffic only. Uploads retain their
+existing request-body behavior. The Cloudflare broker needs no changes.
+
+The client sends encrypted `DeliveryAck` frames on stream zero. Their payload is
+an eight-byte unsigned big-endian cumulative count of received raw tunnel-frame
+bytes on nonzero streams, including the five-byte frame header. Batch envelopes,
+encryption overhead and stream-zero keepalives are excluded. The count resets
+with each handshake. ACKs cover complete frames and include late frames for
+cancelled streams, since those frames still consumed credit. The host rejects
+duplicate, regressing, partial-frame or beyond-sent acknowledgements.
+
+The client acknowledges after decoding and dispatching transport data, without
+waiting for React rendering. It coalesces acknowledgements by byte count with a
+short timer for the tail. Keepalives and ACK processing never await downstream
+credit, which would deadlock the channel.
+
+The scheduler starts with a small byte window. A backlogged sender can grow its
+window when ACK latency stays near the best observed round trip, and reduces it
+when delivery delay rises. Sparse traffic cannot inflate the window for a later
+bulk burst. The window has a hard upper bound; a sudden bandwidth drop can still
+delay bytes already sent, but cannot create an unlimited network backlog.
+
+HTTP bodies and WS messages are sliced into small frames. The scheduler rotates
+streams, preserves each stream's order, and batches selected frames before the
+serialized encryption step. Producers offer a bounded group of slices and await
+transmission before reading more. The legacy timed batcher remains in use only
+without negotiated flow control.
+
+HTTP/SSE backpressure reaches the loopback response reader. Node's `ws` pauses
+loopback socket reads while output is waiting. Bun's `ws` shim cannot pause, so
+the dispatcher instead enforces a connection-wide pending WS byte/message cap
+and explicitly aborts the offending substream on overflow. It never silently
+discards deltas. WS output messages are serialized through their last fragment,
+and the close frame follows pending output. Cancellation releases queued work;
+channel teardown releases all producers and acknowledgement state.
+
+Regression coverage lives in `downstream-scheduler.test.js`, `flow-control.test.js`
+and `cross-compat.test.js`. The end-to-end fixture uses the real client, host,
+crypto and loopback requests with a byte-paced relay leg. It compares delivery
+ordering, queue growth and a concurrent small response, including both legacy
+fallback directions, unbatched operation, cancellation and fragmented WS output.
+It does not replace a physical iOS/LTE check.
+
 ## Authentication model
 
 - The tunnel is **transport only**. The OpenChamber server still authenticates every tunneled request exactly as it authenticates a direct remote client. The relay path grants reachability, not authorization.