feat(gateway): relayed bodies travel on byte channels

Part of #552.

Scope

After this PR, both daemons wrap the uplink with the link (#556), and a
relayed HTTP exchange carries its bodies on a byte channel instead of
base64 relay.body calls and relay-chunk pushes (ADR 0028 §4). Small
calls no longer queue behind relayed bodies, and a slow reader slows only
its own transfer. The relay's own slot limits go: a relay waits only when
the gateway already has 64 channels open to its worker. #552's measured
promises (bytes, timings, memory, 2 GiB) are proven by the task after
this one.

Values used here are in #552's Shared values table.

In short

sequenceDiagram
  participant G as gateway relay *
  participant W as worker relay *
  participant T as relay target (agent-device host)
  G->>G: openChannel() (waits if 64 are open)
  G->>W: relay.request {.., channel}
  W->>W: acceptChannel when the line is read, before startup parking
  G->>W: request body on the channel *
  W->>T: Request (body = the channel's readable)
  T-->>W: Response
  W->>W: STOP the request direction if the target did not read it all
  W-->>G: relay-head
  W-->>G: response body on the channel *, then END
  W-->>G: relay.request answer (may come before END)
  Note over G: the caller's body ends only at END

(* = changed.) If this goes wrong, an upload or download through a
gateway arrives corrupt or short, or hangs, and agents on that worker see
commands time out.

Technical spec

Facts

Modules touched

flowchart LR
  GU["daemon/gateway-uplink.ts *"] --> LK["link (#556)"]
  GS["gateway/service.ts *"] --> LK
  GS --> WL["gateway/worker-link.ts *"]
  WL --> WC["gateway/worker-client.ts *"]
  GR["gateway/relay.ts *"] --> WC
  WC --> CL["simlock-client: client.ts *, wire.ts *"]
  SV["daemon/server.ts *"] --> RL["daemon/relay.ts *"]
  DS["daemon/dispatch.ts *, dispatcher.ts *"] --> RL
  GD["gateway/dispatcher.ts *"]
  CT["contract: operations, pushes, relay, protocol *"]

(* = changed; src/daemon/main.ts passes the new types through.)

Wiring (F12). GatewayUplink#dial wraps the dialled connection with
createLink(…, { end: "worker" }) before accept; GatewayService#accept
wraps the accepted one with end: "gateway" and hands the WorkerLink an
uplink whose connection is the LinkConnection. GatewayUplinkOptions.accept,
DaemonServer#acceptUplink, WorkerClientFactory and WorkerLink's
uplink take a LinkConnection.

Contract (F1–F3, F19). relay.request gains channel, 1–32
characters of [A-Za-z0-9-], as an exported relayChannelSchema that
the operation's schema uses. relay.body, the relay-chunk push, the
chunk bounds and onRelayChunk (F11) go; the gateway dispatcher's
relay.body refusal goes. This PR bumps the protocol by one.

Gateway (src/gateway/relay.ts, worker-client.ts, worker-link.ts).

• GatewayWorkerClient gains openChannel(options: { signal: AbortSignal }),
  which defaultConnect takes from the LinkConnection it is given. The
  relay methods lose relayBody; the hooks lose onRelayChunk.
• An exchange opens a channel with a signal that aborts on its deadline
  or its caller's abort, then sends relay.request naming it. The channel
  wait counts against the deadline (F4). WorkerSlots goes.
• It pipes the caller's request body into the channel's writable, or
  closes the writable at once when there is none. When that writable
  errors with stopped, it stops reading the caller's body.
• The exchange keeps owning the caller's body stream (F5): it reads the
  channel's readable into its own stream, so errors map as below and a
  caller's cancel sends relay.cancel and aborts the channel. The body
  ends at the channel's end, never at the answer; a {} answer only
  settles the call. The deadline and the caller-abort listener (F22) stay
  live until the channel's end, so a worker that answers and never ends
  the body hits the deadline.
• On every end of the exchange (answer, failure, cancel, deadline) the
  channel ends or is aborted, so it leaves the 64.

Worker (src/daemon/server.ts, relay.ts, dispatch.ts,
dispatcher.ts).

• Only on the gateway uplink (isGatewayUplink): when the server reads a
  relay.request line, it parses channel with relayChannelSchema and,
  if it passes, calls acceptChannel before dispatching, so a request
  that parks for startup (F9) holds its channel. If either fails, the
  call later fails BAD_REQUEST. Off the uplink nothing is accepted and
  the handler answers FORBIDDEN as today.
• RelayConnection owns an accepted channel from that moment. Every way
  relay.request fails aborts the channel: schema, access, protocol
  mismatch and DAEMON_STOPPING (F21), startup failure, duplicate
  relayId, missing target, closed connection, a request it cannot
  build, target error, target headers out of bounds, a response body that
  fails after the head (F20), and cancel. A successful {} answer is
  written only after the response direction's END has been written, and
  does not abort.
• The target's Request body is a stream the relay owns, fed from the
  channel's readable as the target pulls (null with hasBody: false).
  Once the target has answered, the relay cancels its own reader on the
  channel, which sends STOP for any unread rest; with hasBody: false
  it does so at once. The response body is piped into the channel's
  writable, which then closes. relay-head stays a push. RelayBodyFeed, the
  relay.body handler and MAX_ACTIVE_RELAYS (F7) go.

Failure mapping. How each side reports a channel failure
(LinkChannelError.reason, #556):

A request parked for startup whose channel has already failed answers by
this table without running its target.

Other tasks. #531 and #533 (task:ready) and #348 also bump the
protocol and change src/daemon/server.ts, dispatcher.ts and main.ts.
As for those tasks, they run at the same time: whichever merges second
takes the base branch and bumps again.

Contract and event changes

• relay.request gains channel; relay.body and the relay-chunk push
  go; the chunk bounds go. This PR bumps the protocol by one.
• No events.

Other code on the same state

The state is a relay's channel and the calls in flight on the uplink.

• The link (#556): owns the channel limit, credit, lanes, STOP and
  the 30 s and 60 s waits; the relay reads its failure reasons (table).
• The agent-device front on the gateway (src/daemon/main.ts:1058):
  unchanged; it gets a Response as before.
• The agent-device host's 2 GiB check (#557): acts on the target's
  response on the worker before the relay pipes it; an errored body is a
  worker-side aborted channel (table). Either order of merge works.
• WorkerLink refresh calls (10 s timeout,
  src/gateway/worker-link.ts:43) and forwarded lease calls: now go
  in the link's priority lane.
• Worker startup parking (F9): the channel is accepted before
  parking; an upload parked over 60 s fails stalled.
• Connection close (src/daemon/server.ts:1576): still aborts every
  relay; the link fails every channel with closed.

Rules in play

• architecture.md: rule 10 (the channel limit lives only in the link;
  the channel bound only in relayChannelSchema), rule 11 (the deadline covers the
  channel wait).
• safety.md: rule 10, channel is wire input: its shape is checked
  with relayChannelSchema before it is used to accept a channel.

Tests

Seam: startFleet (real gateway and worker over the real WebSocket, fake
relay target) and startPair (in-memory) in
src/daemon/relay-gateway.e2e.test.ts, and openUplink in
src/daemon/relay-worker.e2e.test.ts, whose test end now wraps its pair
end with the link. The startup tests are modelled on
src/daemon/server.test.ts:1241. The tests in F17 are deleted or
rewritten as below.

• through startFleet, the worker's server and the gateway's worker link hold link connections, and a relayed GET crosses on a channel
• a 20 MiB PUT body arrives at the target byte for byte, and a 20 MiB response body comes back byte for byte (as today)
• an empty upload (0 bytes) and a GET relay as today
• with 63 relays to one worker held in their targets, a 64th starts at once; a 65th starts once one of them ends; a 65th whose 200 ms deadline passes first fails WORKER_UNREACHABLE with the deadline message; a 65th whose caller aborts while it waits fails at once with the abort reason
• after 64 relays to one worker that were cancelled, timed out, failed with a missing target, or whose target answered without reading its upload, a 65th starts at once
• through openUplink, a relay.request that fails on its schema, a duplicate relayId, a missing target, a target error, target headers out of bounds, a response body failing after the head, or startup failure leaves the test end's channel errored aborted
• a duplicate active relayId fails BAD_REQUEST, and a relay.cancel for an unknown id answers {} (as today)
• a worker that answers {} and never ends the response body: the caller's body errors with the deadline message
• with the worker's transport held so the {} answer overtakes a 20 MiB response, the caller still gets every byte, and its body ends only at the channel's end
• a target that answers 401 without reading its 20 MiB upload: the caller gets the 401 and its body, and the gateway stops reading the caller's body
• a hasBody: false relay whose channel still receives bytes: the worker stops that direction and the gateway's writer errors stopped
• each failure reason maps as the table says, on the gateway before and after the head and on the worker
• a caller's cancel of the body stream sends relay.cancel, aborts the channel and aborts the target's request
• a relay.request on the uplink naming a channel the gateway never opened or one already accepted fails BAD_REQUEST; with channel missing or out of bounds it fails BAD_REQUEST
• relay.request and relay.cancel from a session that is not the gateway uplink answer FORBIDDEN (as today)
• a relay sent while the worker is still starting holds its channel, and its 2 MiB upload arrives in full once startup converges
• a relay whose 8 MiB upload stays parked by worker startup for 60 s fails INTERNAL on the gateway with the 60 s message
• a parked relay whose channel failed while it waited answers by the table without running its target
• a GET, a HEAD, and 204, 205 and 304 answers relay with a null body (as today)
• caller abort, request-body error, deadline, uplink drop, no uplink, missing target, header filtering, 101 headers, target throws, body error after head, and relay plus device.exec isolation behave as today (relay-gateway.e2e.test.ts:332, :527–:706; relay-worker.e2e.test.ts:101–:147, :409–:427; :437 rewritten to read the response from the channel)
• OPERATIONS has no relay.body, PUSH_SCHEMAS no relay-chunk, and SimlockAdminClient as simlock/admin exports it has no relay methods
• a worker one protocol version behind the gateway is listed as incompatible (as today, with the bumped range)

Done when

• Every Tests line passes.

Out of scope

• The 2 GiB download cap (#557).
• Any change to the link itself (#556).
• Live streaming.
• The measured promises and the slow-lane timing (#559).

Depends on

• #556

Written by an agent.