aNonMembersFrameNeverEntersTheRoom

The mirror of (a) and (c), and the half of the membership boundary #2307 found unasserted.

A peer the policy admits to table-7 and refuses for table-9 puts a frame on table-9's channel — which a NamedMux client can do at will over the one connection it already holds. That frame must reach neither table-9's hub inbox (Seam.incoming) nor table-9's members, and must not put its sender in table-9's roster or its fanout.

The anchor — why "it was dropped" is provable here rather than assumed

Every absence assertion below would be green if the intruding frame had merely not been read yet, and a bounded wait cannot tell those apart. So the frame's disposition is settled before anything is asserted, by a sequencing anchor: immediately after the intrusion the same connection sends a frame on table-7, a room that peer is in, and the test waits for that frame at table-7's hub inbox. A server reads one connection with a single sequential collection, so the anchor's arrival proves the intrusion was already dequeued and dispatched. That is a happens-before, not a timing guess, and it holds for a real-I/O backend as strongly as for an in-memory one — unlike anything keyed to a second connection's ordering, which nothing guarantees. It is also the rig-fired receipt for the send itself: without it, a harness whose channel("table-9").broadcast silently did nothing would pass this test with no ingress attempt ever made. What the anchor deliberately does not claim is which branch dropped the frame — it proves the server's read path handled it, and the room boundary is what is under assertion.

The second rig receipt is RefusingAuthorizer.refusals, which counts the consultations that returned false for the refused pair. That pins RoomAuthorizer's own documented invocation contract ("invoked once per connection per room tag when a connection first emits a frame on that channel") rather than adding an obligation, and it is what distinguishes "the frame was refused" from "the frame never reached the room's gate at all".

The positive controls

Each of the three destinations is proved observable by a frame that does arrive on it, sent only after the anchor:

• the hub inbox — a member's own frame, drained for and found;

• the member's inbox — a hub broadcast, drained for and found;

• the intruder's own table-9 view — the only one with no positive control available, since nothing may legitimately be delivered to it. Its silence is bounded by absenceBudget and is the weakest assertion here; it is anchored by the member having received the very broadcast whose fanout list the intruder must be absent from, so a broadcast provably happened between the intrusion and the check.

Mutation receipt

Reference: us.tractat.kuilt.core.RoomHubSeam.deliver. Spooling the frame on the rejected branch — if (!authorizer.authorize(…)) { inboundSpool.deliver(frame); return }, i.e. keeping the registration guard and dropping only the ingress guard, which is exactly the admitted-to-inbox-while-excluded-from-fanout backend #2307 describes — reddens this test on the hub-inbox assertion and leaves all four pre-existing properties green. That single row is the whole argument for this property's existence. Deleting the authorization check outright reddens this test and rejectedConnectionIsStructurallyExcluded, which is the weaker control.