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/075-channelsadapter-and-channelmanager.md

@@ -2,7 +2,26 @@
 
 ## Status
 
-Accepted
+Accepted (amended 2026-07-18 by ADR-093 — demux reads 8-byte headers, not
+9-byte; one reassembly buffer per `channel_id` (not per
+`(channel_id, stream_type)`); `ChannelState.stream_types` removed; the
+channels layer has no `stream_type` concept — see "Amendment (ADR-093,
+2026-07-18)" below)
+
+## Amendment (ADR-093, 2026-07-18)
+
+The demux loop reads **8-byte headers** (not 9-byte). `ChannelState` has
+**one reassembly buffer per `channel_id`** (not per
+`(channel_id, stream_type)`), yielding a `BiStream` to the handler. The
+`stream_types: Vec<u8>` field on `ChannelState` is **removed**. The
+`ChannelManager` has no `stream_type` concept — it routes by `channel_id`
+only, and the handler owns its sub-stream multiplexing on the `BiStream`
+it receives (per ADR-093, the channels-layer consequence of ADR-092's
+`BiStream` handler leaf).
+
+The body below describes the **original** (9-byte, per-stream_type) shape;
+the amendment above is the operative decision. See ADR-093 for the
+resolution rationale and the cross-ADR impacts.
 
 ## Context
 
@@ -224,11 +243,14 @@ contract.
 
 ## References
 
-- ADR-071: channels wire format (the chunks the demux reads)
+- ADR-071: channels wire format (the chunks the demux reads, as amended
+  by ADR-093 — 8-byte header)
+- ADR-093: channels pure channel multiplexing (amends this ADR — 8-byte
+  header, one reassembly buffer per channel, no `stream_type` concept)
 - ADR-072: channel 0 pre-negotiated (the `preinstall_channel_0` step)
 - ADR-073: channel lifecycle operations (the ops registered on `call_ops`)
 - ADR-074: ChannelBidiStreamSource (the per-channel source the manager
-  constructs)
+  constructs, as amended by ADR-093 — `accept_bi` yields a `BiStream`)
 - ADR-076: backpressure, channel limits, ID reuse (the `buffer_cap` /
   `max_channels` / reuse invariants)
 - `docs/research/alknet-channels/poc-summary.md` §Issues Surfaced #4-#6