What
The internal SDK event stream that reports command progress gained a refused state for a peer message turned away by the session's receive-side policy before it ever joined the queue, so it is never preceded by "queued". The existing discarded state now also covers a session ending while such a message is still held.
Details
- The schema documents a known gap: the queue's own admission checks (rate limit, duplicate collapse, loop guard, queued-peer cap) can leave a message in "queued" with no terminal state.
- The git-operation event docs now note that pushing several branches emits one event per branch.
Evidence
declined by the session's receive-side policy before entering the queue
Strings lifted out of the shipped bundle, so the claim above can be checked against them.