sec: drop BroadcastMu to remove head-of-line blocking on slow subscribers

[EthanY33]

Summary

Closes #12.

Broadcast held BroadcastMu for the entire iteration over the subscriber set. Under PolicyDisconnect's 10s writeDeadline, a single TCP-paused subscriber wedged every publisher to that channel for up to 10 seconds. An attacker who could open one socket and stop ACKing-down-the-stack effectively held the channel hostage.

Drop the mutex. Per-subscriber FIFO ordering — the only guarantee the protocol promises — is preserved by Go's chan-send ordering inside each Conn's send chan: messages arrive at the subscriber in the order Send was called. Cross-subscriber ordering ("every subscriber sees publish A before publish B") was never a documented contract.

Concurrent broadcasts can now interleave their Send calls. Each subscriber still sees its own messages FIFO.

What changed

• internal/registry/registry.go: removed Channel.BroadcastMu field.
• internal/hub/channel.go: Broadcast no longer locks BroadcastMu. Updated comment to explain the ordering guarantee.

internal/* is not part of any external API; the field rename is safe.

Test plan

• go build ./... clean.
• go test ./internal/... passes (pre-existing CGO sqlite failure is environmental, unrelated).
• Stress: 100 publishers concurrently spam channel "X". Subscriber consumes all messages. With the mutex, throughput was bounded by the slowest publisher. After this change, total throughput scales with publisher count up to subscriber's chan capacity.
• Adversarial: one subscriber TCP-stalls. Other subscribers still receive new publishes within tens of ms (was: blocked for up to 10s).

Conflict notes

Touches internal/hub/channel.go and internal/registry/registry.go. PR #20 (channel GC) also touches both files, with a new ErrChannelDeleted error and a Deleted atomic.Bool field. Conflicts are textually adjacent but logically independent — both can coexist. Whichever lands second will need a small textual rebase.