"Steam lobby metadata survives host game switch"

A player joins from the game browser, connects successfully (transport is fine), but the joining game's scene tears down and the client starts downloading a completely different game's map package. The lobby appeared valid in the browser — filtered correctly for the current game.

The engine writes the lobby's "game" metadata key once at creation and never updates it. When the host switches to a different s&box game:

• The Steam lobby survives the game switch (it is not destroyed and recreated).
• Map changes re-set the "map" key and host migration re-sets name/owner/map, but nothing re-sets "game".
• The engine's own per-game browser filter (QueryLobbies with a game-ident key match) still matches the stale creation-time value, so the switched lobby keeps appearing in the old game's browser.
• Any custom lobby-data stamps the origin game wrote (join codes, timestamps) also linger — lobby metadata is creation-time identity, never current state.

A client-side hard reject is infeasible: the lobby information API returns the stale creation ident, and a game's own ident property is internal to the engine (not addon-whitelisted), so a game cannot even read its own ident to compare.

Judge lobbies by a game-written moving liveness beat — a heartbeat key the game re-stamps on a regular interval. A lobby whose beat ages beyond the heartbeat interval is stale (the host left or switched games). Accept the beat-interval staleness window as unavoidable: a just-switched lobby is indistinguishable until the beat ages out.

The real fix is upstream: the engine should update or clear lobby metadata on game switch, or destroy and recreate the lobby.

The heartbeat key is written by your game code (not the engine), so it freezes the moment the host leaves your game. A joiner checking the beat's age before connecting catches stale lobbies within one heartbeat interval, which is far better than trusting the immutable creation-time game tag.