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/decisions/079-hub-relay-translate-not-forward.md

@@ -113,11 +113,13 @@ do the protocol work.
 
 This ADR defines the relay *contract* (translate channel 0, byte-forward
 data channels with ID rewrite) so the channels crate's `ChannelManager`
-exposes the interface the relay needs (`open_channel_stream(channel_id,
-stream_type) -> (SendStream, RecvStream)` for the byte-forward pumps). The
-relay *implementation* lives in `alknet-hub` (or a downstream hub like
-alkapi), not in `alknet-channels`. The channels crate is ALPN-blind and
-does not know it is being relayed.
+exposes the interface the relay needs (`open_channel_stream(channel_id)
+-> BiStream` for the byte-forward pumps). The relay *implementation*
+lives in `alknet-hub` (or a downstream hub like alkapi), not in
+`alknet-channels`. The channels crate is ALPN-blind and does not know it
+is being relayed. The `channel_id` rewrite is a 4-byte field rewrite
+within the 8-byte header (per ADR-093); the relay does not parse the
+payload.
 
 ## Consequences
 
@@ -170,6 +172,9 @@ auth path. The `channel_id` mapping strategy (`HashMap` per pair) is two-way
   terminates on each leg)
 - ADR-073: channel lifecycle operations (what the hub translates)
 - ADR-075: ChannelsAdapter and ChannelManager (the interface the relay uses)
+- ADR-093: channels pure channel multiplexing (the 8-byte header the relay
+  reads/writes; the 4-byte `channel_id` rewrite; the `BiStream`-yielding
+  `open_channel_stream` interface)
 - `docs/research/alknet-channels/phase-0-findings.md` §Hub Motivation,
   §The hub relay, §OQ-CH-11
 - `docs/architecture/crates/hub/README.md` — the hub crate (the relay