Rivet currently allows a client to present the same resume token again while the preious transport is still being torn down. In normal recconects this is harmless, but during a fast network handoff two transports can briefly race to restore the same subscription state. This affects Northstar because its client reconnect flow can open the replacemnet transport before the previous one has fully disappeared. I'd like to agree on the contract at the Rivet boundary rather than relying on client-side timing.

Switching from Wi-Fi to Ethernet while a document is open can leave the previous presence session visible for several seconds after the new connection is established. I can reproduce it consistently when the network handoff happens while the tab is in the background.

This discussion began in `#general` after a user reported that reconnecting could silently overwrite unsent editor changes. The selected messages capture the investigation, the proposed operation-replay approach, the deleted-block edge case, and the resulting recovery behavior we agreed to implement.