feat(send): an ambient send now says who it did NOT wake

[MGrin]

MX-148. sent (ambient) -> room is a true and completely uninterpretable receipt.

It returns cleanly, the room's message count rises — which is the check AGENTS.md prescribes for the --room typo, and it passes here — and the message really is in the room, readable by anyone who looks. What it never said is that nobody was woken.

So an orchestrator broadcast "the slot is FREE, take it" to three idle workers holding finished PRs, and stalled its own queue with a free box and three ready PRs. Nothing was lost or misrouted: "in the room" and "delivered" are different states, and only one causes work to happen.

The fix is the ticket's own suggestion

The count is knowable at send time and is the one fact that would have made this visible, so it is printed:

sent (ambient) -> motion-cluster-stability — stored for recv/log, woke NOBODY.
2 other member(s) NOT woken, 1 of them IDLE. An idle thread will not see this
until it looks; if the message contains an INSTRUCTION, resend with --to <thread-id>.

IDLE rather than membership is what matters. An active thread reaches the room on its own turn; an idle one never does.

The probe is capped at 8 members, deliberately

This is the hot path of every ambient send, and this machine regularly sits at load 50+ with bb dropping writes (MX-138 / MX-146). A broadcast to a large room must not become a burst of API calls. Above the cap the honest answer is the membership count, which costs no calls at all.

Verified against the deployed plugin

• real room with a known mix (2 other members, 1 idle) — the receipt above
• scratch room — sent (ambient) -> mx148-probe — no other members

tsc --noEmit clean, 17 tests pass. The probe message wakes nobody by construction, which is why it was safe to send to a live room.

🤖 Generated with Claude Code