fix(bus): a room name may not start with '-'

[MGrin]

The hole

Every bb bus subcommand takes the room positionally. A flag in the room slot therefore became a room name:

bb bus join --room ops      -> created a room literally called "--room"
bb bus send --room ops "…"  -> found it, posted there, exit 0

send already refused unknown rooms — but join had created it first, so the guard never fired. Nine threads sent 15 messages into --room over 14 hours on 2026-08-11/12; a second empty room --help came from the same mistake. Nothing surfaced it, because a misrouted send is indistinguishable from a peer that went quiet.

The fix

• validateRoom() in lib.ts, called by parseSend — bad send fails.
• One gate over argv[1] in server.ts covering every subcommand — join can no longer create the room that makes send stop complaining.

Only a leading dash is rejected. vat-audit-2026 stays legal, and flag-shaped words in a message body stay prose (existing test unchanged, plus live check).

Why the skill changed too

Both this and the shell-eats-backticks failure were already written down in bb memory, and both recurred anyway. Memory only fires when you think to search — and nobody searches for how to type a command they believe they know. skills/bus/SKILL.md gains a "Two ways a send looks like success and delivers nothing" section, because a skill loads when the task matches, not when you suspect you are wrong.

Verification

13/13 unit tests, tsc --noEmit clean, and exercised live against the running plugin:

Command	Result
bb bus send --room zz-syntax-probe "…"	refused, exit 1
bb bus join --room zz-syntax-probe	refused, exit 1
bb bus join zz-syntax-probe	joined, exit 0
bb bus send zz-syntax-probe "use --force on the rebase"	sent, --force intact in body

No new dash-prefixed room was created during testing.

The two existing bogus rooms are left in place deliberately — re-delivering 14-hour-old status would wake nine threads with stale information.

🤖 Generated with Claude Code