Right now an operator's answer message rides a priority queue that pierces a paused room, so it gets delivered even while the room is otherwise paused. That might be the right call for control-plane traffic, but it's not a deliberate design decision, it's just how the merge happened to fall out of the seq-sort implementation.
Sketch: decide on purpose whether human/answer traffic should route through the normal queue like everything else, so a paused room holds answers too and pause means pause, or keep the current priority-queue/seq-sort merge that lets it through regardless of pause state. Whichever way this goes, write it down as an explicit invariant instead of leaving it implicit in the merge logic.
If the routing behavior changes, that needs a PROTOCOL_VERSION bump; if it's just documenting the existing behavior as intentional, it doesn't.
Right now an operator's answer message rides a priority queue that pierces a paused room, so it gets delivered even while the room is otherwise paused. That might be the right call for control-plane traffic, but it's not a deliberate design decision, it's just how the merge happened to fall out of the seq-sort implementation.
Sketch: decide on purpose whether human/answer traffic should route through the normal queue like everything else, so a paused room holds answers too and pause means pause, or keep the current priority-queue/seq-sort merge that lets it through regardless of pause state. Whichever way this goes, write it down as an explicit invariant instead of leaving it implicit in the merge logic.
If the routing behavior changes, that needs a PROTOCOL_VERSION bump; if it's just documenting the existing behavior as intentional, it doesn't.