docs(adr): 093 — channels pure channel multiplexing (8-byte header, no stream_type)

Prune the channels spec to reflect the stream-unification resolution
(docs/research/stream-unification/findings.md): the channels wire format
goes from 9 bytes to 8 bytes, the channels layer no longer carries a
stream_type concept, into_sub_streams() is removed, and TTY always uses
its 5-byte format (carried transparently in the channels payload).

ADR-093 is the umbrella decision (the channels-layer consequence of
ADR-092's BiStream handler leaf): every channel is a BiStream, the
handler owns its sub-stream multiplexing, the channels layer routes by
channel_id only. Amends ADR-071 (8-byte header, no stream_type),
ADR-074 (into_sub_streams removed, accept_bi yields BiStream), reverses
ADR-077 (TTY always 5-byte), and the channels-facing clauses of
ADR-072/073/075/076/080/081. Adds ADR-092 forward-reference note
(into_sub_streams preservation subsequently reversed by ADR-093) and
the missing ADR-092 cross-reference on ADR-070.

Adds OQ-68 (add/strip API shape — built-in vs utility; the contract is
decided in ADR-093, the function surface is open; two-way door, low
priority, decision-ready when the channels crate's implementation
begins).

Rewrites the 7 channels spec docs (README, overview, channels-wire,
channels-connection, channels-adapter, channel-operations, channel-client)
to describe the post-amendment shape as current, with the 8-byte header,
the add/strip composition, single accept_bi accessor, BiStream per
channel, and TTY-always-5-byte.

Touch-up cross-references in hub README, client README, ADR-085, and
the OQ-45/47/65 question files (TTY-internal stream_type 3 →
STREAM_CTRL_IN; channels 9-byte → 8-byte).

docs/architecture/questions/045-flow-control-for-high-throughput-stdout.md

@@ -47,11 +47,12 @@
   can't keep up; no unbounded buffer breaks the chain.
 
   The two-way-door reversal — a per-stream window-update control message
-  on stream_type 3 — is an additive extension to the control channel
-  (a new `ControlMessage` variant), not a wire-format header change. It
-  is not the expected path; it is noted in ADR-052's consequences as the
-  cheap reversal if a flow-control problem ever surfaces that QUIC's
-  defaults cannot handle (e.g., a pathological stream that needs
+  on TTY's `STREAM_CTRL_IN` (stream_type 3) — is an additive extension
+  to the control channel (a new `ControlMessage` variant), not a
+  wire-format header change. It is not the expected path; it is noted
+  in ADR-052's consequences as the cheap reversal if a flow-control
+  problem ever surfaces that QUIC's defaults cannot handle (e.g., a
+  pathological stream that needs
   sub-QUIC-window backpressure signaling). Tuning concerns (read buffer
   size, channel depth) are implementation-level, not architectural, and
   don't warrant an ADR.

docs/architecture/questions/047-stdin-closure-canonical-signal.md

@@ -8,14 +8,15 @@
 - **Priority**: low
 - **Resolution**: Either a zero-length stdin chunk (stream_type 0,
   length 0 — the docker POC's sentinel) or a `{"type":"eof"}`
-  control chunk (stream_type 3 — the tty POC's explicit signal) closes
-  the client's stdin. Both are accepted by the adapter; the spec
-  recommends `eof` for explicitness (it's a control message, not a
-  data-length hack). The adapter handles both identically: signal EOF
-  to the backend's stdin (`ChildStdin::drop` / PTY writer close) and
-  keep pumping stdout until the exit resolves — the client may still
-  want to receive remaining output + the exit code. A third path
-  (client closes the write half of the bidi stream) is also accepted
-  and handled the same way. See ADR-052 and `tty-wire.md`.
+  control chunk (TTY's `STREAM_CTRL_IN`, stream_type 3 — the tty POC's
+  explicit signal) closes the client's stdin. Both are accepted by the
+  adapter; the spec recommends `eof` for explicitness (it's a control
+  message, not a data-length hack). The adapter handles both
+  identically: signal EOF to the backend's stdin (`ChildStdin::drop` /
+  PTY writer close) and keep pumping stdout until the exit resolves —
+  the client may still want to receive remaining output + the exit
+  code. A third path (client closes the write half of the bidi stream)
+  is also accepted and handled the same way. See ADR-052 and
+  `tty-wire.md`.
 - **Cross-references**: ADR-052, [tty-wire.md](crates/tty/tty-wire.md),
   [tty-adapter.md](crates/tty/tty-adapter.md)

docs/architecture/questions/065-websocket-carrying-channels.md

@@ -41,13 +41,13 @@
 
   **Option B — WebSocket carries channels (extends/supersedes
   ADR-048).** The browser opens a WebSocket and gets a channels
-  connection — the 9-byte chunk format (ADR-071) over WebSocket binary
-  frames, with channel 0 as `alknet/call` and data channels opened via
-  `channel/open`. The browser is a full channels participant: it can
-  open TTY channels, tunnels, etc. through the same WebSocket. The
-  hub relay (ADR-079) works unchanged — the browser leg is a channels
-  connection, same as a native leg. This is the "browser as
-  channels client" path.
+  connection — the 8-byte chunk format (ADR-071, as amended by ADR-093)
+  over WebSocket binary frames, with channel 0 as `alknet/call` and
+  data channels opened via `channel/open`. The browser is a full
+  channels participant: it can open TTY channels, tunnels, etc. through
+  the same WebSocket. The hub relay (ADR-079) works unchanged — the
+  browser leg is a channels connection, same as a native leg. This is
+  the "browser as channels client" path.
 
   The trade-off: Option B commits to the channels-over-WebSocket
   framing as a browser wire format (one-way door), but makes the
@@ -73,8 +73,10 @@
   format (ADR-071); only the transport differs.
 - **Cross-references**: ADR-048 (WebSocket carries the native
   call-protocol session — the current decision this OQ may supersede
-  or extend), ADR-071 (channels wire format — the 9-byte chunk format
-  that would ride over WebSocket binary frames), ADR-079 (hub relay —
-  unchanged if the browser is a channels client), ADR-086 §3 (the web
-  config advertises `alknet/channels` for this path), ADR-044
-  (WebTransport deferred; WebSocket is the v1 browser path)
+  or extend), ADR-071 (channels wire format — the 8-byte chunk format
+  that would ride over WebSocket binary frames, as amended by ADR-093),
+  ADR-093 (channels pure channel multiplexing — the umbrella decision),
+  ADR-079 (hub relay — unchanged if the browser is a channels client),
+  ADR-086 §3 (the web config advertises `alknet/channels` for this
+  path), ADR-044 (WebTransport deferred; WebSocket is the v1 browser
+  path)

docs/architecture/questions/068-channels-add-strip-api-shape.md

@@ -0,0 +1,78 @@
+# OQ-68: Channels Add/Strip API Shape (Built-In vs. Utility)
+
+- **Origin**: `docs/research/stream-unification/findings.md` §"The
+  add/strip utility"; `docs/architecture/decisions/093-channels-pure-channel-multiplexing.md`
+  §"What this ADR does NOT decide"; `docs/architecture/crates/channels/channels-wire.md`
+  §"The add/strip composition"
+- **Status**: open
+- **Door type**: two-way (the *contract* — channels strips its 8-byte
+  header on read, handler parses its own framing from the payload — is
+  decided in ADR-093; the *function surface* — whether add/strip is
+  built into the read/write path or exposed as a standalone utility —
+  is reversible without breaking the wire format or the handler contract)
+- **Priority**: low
+- **Impacts**: None — the add/strip *contract* is decided (ADR-093);
+  this OQ is about the API shape, not the contract. The channels crate
+  can ship with either shape and switch later without a wire-format
+  change.
+- **Investigation target**: work through 2+ example handler
+  compositions (TTY inside channels, tunnel inside channels, a
+  recursive `alknet/channels`-inside-`alknet/channels` composition) to
+  see where the add/strip naturally lives. If the header add/strip is
+  built into the channels read/write path, the handler never sees the
+  `channel_id` — the `BiStream` the handler receives is the payload
+  bytes. If the add/strip is a standalone utility, the handler (or a
+  test helper, or the hub relay's `channel_id` rewrite) can call it
+  explicitly. The question is which shape is cleaner for the common
+  case (handler inside channels) without foreclosing the
+  less-common cases (recursive composition, the hub relay, test
+  helpers).
+- **Resolution**: Not yet decided. The two options:
+
+  **Option A — Built into read/write (the default).** The channels
+  layer's `accept_bi` returns a `BiStream` whose bytes are the payload
+  (the channels header is stripped internally). The handler's
+  `AsyncWrite` on the `BiStream` re-adds the 8-byte header internally
+  (the handler writes payload bytes; the channels layer frames them).
+  The handler never sees the `channel_id`; the add/strip is invisible.
+  This is the cleanest shape for the common case (a handler inside
+  channels). The utility (`add_channel_id` / `strip_channel_id`) is
+  still available internally (the channels layer calls it), and may
+  be exposed publicly for the less-common cases (recursive composition,
+  the hub relay, test helpers) — but the handler boundary doesn't
+  require it.
+
+  **Option B — Standalone utility (the explicit alternative).** The
+  channels layer exposes `add_channel_id(channel_id, payload_bytes)
+  -> chunk` and `strip_channel_id(chunk) -> (channel_id,
+  payload_bytes)` as the primary API. The handler (or a wrapper, or a
+  test helper) calls them explicitly. This is the shape the
+  stream-unification research proposed. It's more explicit (the
+  handler sees the `channel_id`, can log it, can route on it) but
+  pushes the add/strip to the handler boundary, not the channels
+  read/write path. The handler's `BiStream` is the raw chunk bytes
+  (header + payload), not the payload alone.
+
+  The trade-off: Option A is cleaner for the common case (the handler
+  doesn't care about `channel_id`; the channels layer owns it
+  entirely) but may require an escape hatch for the less-common cases
+  (the hub relay needs to rewrite `channel_id`; recursive composition
+  needs to re-add a header; test helpers may want to construct chunks
+  directly). Option B is more uniform (the same add/strip pair at every
+  level, including the handler boundary) but pushes work to the
+  handler that the channels layer could own. The investigation target
+  (2+ example compositions) is what surfaces which shape is cleaner in
+  practice.
+
+  This question is decision-ready when the channels crate's
+  implementation begins. Until then, the *contract* (channels strips,
+  handler parses payload) is decided (ADR-093); the *function surface*
+  is not.
+
+- **Cross-references**: ADR-093 (the umbrella decision that decides the
+  add/strip *contract* and leaves the *function surface* to this OQ);
+  `docs/research/stream-unification/findings.md` §"The add/strip
+  utility" (the research that proposed the utility);
+  `docs/architecture/crates/channels/channels-wire.md` §"The add/strip
+  composition" (the spec that records the contract and points to this
+  OQ)