Async receive middleware can reorder a presence and its own leave #767

receive middleware runs separately for each message, and nothing makes one message wait for the previous one. If a client sends a presence and then its leave (p: null), and async receive middleware with uneven latency (for example a per-message auth lookup) lets the leave reach Agent._handleMessage first:

1. The leave is broadcast, and receivers drop the presence.
2. The older presence arrives, replaces the stored leave, and is broadcast.
3. Receivers keep it as a ghost until that client unsubscribes or disconnects.

The reverse can also happen: a presence re-created with the same id after its leave is dropped if it overtakes that leave.

This isn't a regression. #751 closes the same reorder for everything after receive middleware (doc version lookup, receivePresence, transform), but the order it uses is the order messages reach _handleMessage. A fix would take that order before receive middleware instead, for example by stamping each message as it arrives in the agent.