"Quit-to-menu teardown runs inside DisconnectScope — networking is still active"

A persisted "host closed the world" notice replays as a stale modal on the next boot, even though the player quit locally. Or: after a host crash, the poisoned-pair transport state between two SteamIDs persists because no graceful disband was sent (see steam-p2p-session-poisoned-pair).

Quit-to-menu tears the game scene down inside Networking.DisconnectScope, so networking is still active during game-side teardown.

This has two consequences worth designing around:

1. A guest quitting locally is distinguishable from being disbanded by the host. Networking-still-active during teardown means a local exit. A persisted "host closed the world" breadcrumb must therefore be rewritten (cleared) on a local quit, or it replays as a stale modal on the next boot.

2. Teardown code can still send graceful goodbyes. Because networking is still up at that point, a host can run its kick/disband sweep on engine-initiated closes — this is the only place the poisoned-pair problem can be avoided at the source.

• Clear session-scoped breadcrumbs on local quit. Any persisted notice state (like "host closed the world") must be rewritten when the player exits locally, not only when the host disbands.
• Send graceful disband/kick sweeps during teardown. Route every host exit through a goodbye sweep while networking is still active, reducing the window for poisoned-pair transport state.

The networking-still-active window during teardown is a design hook, not an accident. Using it for graceful goodbyes means the host can notify all connected peers before the transport shuts down, and using it to distinguish local vs remote exit prevents stale state from replaying incorrectly.