v0.3.7 — a reachable channel ceiling, and delivery written down

Two consumer questions, both of which turned out to have answers worse than the questions assumed.

The Arcanum conduit ceiling could not be reached

ConduitCodec.MaxChannelPayloadBytes was FrameCodec.DefaultMaxFrameSize exactly. A payload at that size encodes to 17 bytes more than a frame may carry, and with the Veil's nonce and tag and the vessel header it reached 16,777,266 against a 16,777,216 limit.

So the documented maximum was unsendable — and the refusal came from FrameCodec, at the transport, quoting frame bytes rather than the payload number the caller chose. That was the single place the library broke its own rule that a ceiling fails at the rite, with a reason.

Now: a frame less 64 KiB of headroom, for precisely the reason the Pilgrimage ceiling sits 64 KiB under the browser's 256 KiB — a payload is not what goes on the wire.

⚠️ Behaviour change. MaxChannelPayloadBytes drops from 16 MiB to 16 MiB − 64 KiB. Nothing that previously succeeded now fails: payloads in that band could never be sent. Read the figure from ConduitSession.MaxPayloadBytes rather than hard-coding it and the change is invisible.

Conduit delivery is ordered but not guaranteed

Now stated, because it was not written down anywhere:

• Frames arrive in order, never torn or duplicated.
• They are not retried. Only the Epistle has the Vigil.
• A receiver that stops draining fills its per-stream queue, and past that Ward further frames are dropped silently — the queue write reports success, and nothing in a frame reveals a gap.

An Epistle lost that way returns on the next retry; a conduit frame is gone and neither end finds out. Reachable only by a receiver that lets a thousand frames queue, so the shape that cannot lose anything is to take each frame and come straight back rather than processing inline. A protocol that must detect loss rather than avoid it carries its own sequence number.

Documented on ConduitFrame, on ReceiveAsync, and as its own section in design/transports-and-limits.md.

Also

design/transports-and-limits.md now says what "any transport" does and does not mean for a Shrine, and carries the authoritative account of where the send-concurrency guarantee comes from — NoiseVessel on every authenticated path, per-rite locks for bare vessels, IVessel owing nothing.

440 unit tests green.