Presence from one client can be published out of order #768

Agent decides which of a client's presence updates for an id is newest by pv, plus the order requests reach _broadcastPresence. Neither holds in two cases, both on main today:

1. A presence re-created with the same id straight after its leave is lost:
   1. localPresence.destroy() (or localPresence.submit(null))
   2. Immediately presence.create(sameId).submit(value)
   3. The new presence (pv 0) reaches receivePresence before the leave, which waits a tick in _unsubscribeDocVersion. It isn't stored over the old pv 0, the leave is published last, and remote clients show nothing
2. A leave that overtakes an older update for the same id in async receive middleware is followed by that update, so remote clients keep a ghost presence until the client unsubscribes or disconnects.

Remote clients can't untangle either: pv restarts at 0 when a presence is re-created, and a leave wipes the remote's pv history for that id.

A per-agent counter stamped on each message before receive middleware runs would give the server one order to go by: accept a presence only if it's newer than the last one accepted for that channel and id. It would also replace the pv and arrival-order rules #751 adds to drop presence that a leave has overtaken.