NewSegment dispatched AddPlaybackSegment through ss.Go, which dispatched AddToWebRTC through ss.Go again — so each segment's packetize (a full gst pipeline, ~100-400ms with high variance) raced every other segment's and PublishSegment order could invert. On streams with short GoPs (1s keyint), packetize latency variance is comparable to the inter-segment interval, so inversions fire constantly; WebRTC playback, the only consumer that plays segments strictly in arrival order, showed each swap as frame loss at a keyframe. Each rendition now gets its own ordered queue + worker: publish order always equals enqueue order, one rendition's backlog never delays another's, and a full queue drops the incoming segment (counted in streamplace_playback_queue_dropped_total) rather than blocking the director's segment loop. Workers drain on session teardown so the stream's tail still publishes. Also removes the dead StreamSession.packets field.