release the stale reply binding of a buffered push

[patric-vinicios]

startTimeout can run twice for the same push, and the second run leaves the first one's binding behind.

It happens whenever a push goes out on a channel that isn't joined yet. Channel.push calls startTimeout() and parks the push in pushBuffer;
once the join is acked the buffer gets flushed through Push.send, which calls startTimeout() again. Each call mints a fresh ref and registers a new chan_reply_* binding, but nothing releases the one from the first call — cancelRefEvent only knows about this.refEvent, and that's already been overwritten by then.

So the first binding just sits there. The push never went out under that ref, so the server never replies to it, so it never fires and never cleans itself up. It stays on channel.bindings for as long as the channel lives, and since the callback closes over the Push, the payload stays reachable with it. Channel.trigger walks that array on every message that comes in.

The window is narrow but it gets hit constantly — everything between join() and the join ack, plus the entire time a socket is down. Which is exactly when pushes get buffered in the first place.

Against a real server, 25 pushes during the join window plus another 25 across a reconnect leave 50 dead bindings, and all 50 payloads are still reachable after a forced GC. Both go to zero with this change. A push sent while the channel is joined gets collected either way, which acts as the control.

Dropping the old binding can't lose a real reply. A buffered push never hit the wire under the old ref, since Push.send is the only thing that calls socket.push and it hasn't run yet. Every other path into startTimeout (resend, the join push, leave, an ordinary push) has refEvent at null already, so the extra call does nothing.

One thing about the test: it restores the real makeRef. The existing describe("push") block stubs it to a constant, which lands every reply binding on chan_reply_1 — and since channel.off(event) clears all bindings for an event, the leaked one gets swept up along with the live one. That's why the suite never caught it.

@xh4 worked out the mechanism back in #4948. That issue got closed asking whether the regenerated ref actually caused a problem, and the numbers above are the answer to that.

[SteffenDE]

Thank you! 🙌🏻