Fix JOIN race: pin NAMES/broadcast to atomic membership snapshot

Two clients JOINing the same channel concurrently could each see the
other in their own NAMES reply, and both could end up auto-opped on
a freshly-created channel.  The cause was that join-one! did:

  (swap! channels update handle (fnil conj #{}) nick)
  ...
  (get @channels handle)   ;; for NAMES + broadcast + auto-op

Between the swap! and the @channels read, a peer's swap! could land,
so the read returned a set that already included them.

Switch the swap to swap-vals!, capture members-before / members-after
as a snapshot of state at the moment of our atomic update, and feed
that snapshot to the broadcast loop, the metadata-2 push, the away-
notify push, the auto-op decision, and the NAMES reply (via a new
:members keyword on names-for).  Auto-op now keys off (empty?
members-before) instead of comparing the live atom to #{nick}.

Surfaced and verified by the differential test in chat.papo.im,
which previously had to insert quiesce checkpoints between concurrent
JOINs to dodge the race; those checkpoints are no longer needed.

0 files changed, 0 insertions, 0 deletions