Three places delivered a burst of segments in whatever order the scheduler or the gateway finished them: the validated-segment fan-out started a goroutine per subscriber per segment, the bus did the same onto an unbuffered channel, and a stream's transcodes and packetizers run concurrently, so rendition playlists, WebRTC feeds and syndicating peers all saw segments out of order (a viewer watched a rendition play segments backwards). Now every subscriber of validated segments has its own ordered queue and forwarder; the bus feeds each subscriber's buffered channel in publication order itself, dropping only for a subscriber a thousand segments behind (and its replay of recent segments, which was built and then thrown away, reaches the subscriber); and each stream session hands out turns in arrival order — one lane for the source segments, one for the renditions — that a segment's publication waits for once its packetizing or transcoding is done, giving up on a predecessor stuck longer than 15 seconds. A rendition's window feed, its addendum to peers and its WebRTC segments are published together in that turn Claude-Session: https://claude.ai/code/session_014aPQ5yqG9QFxKnbwQfCYKa (cherry picked from commit 57eed20b64e28a80fc631510c1ddff6a2169d160)