"Gate the exact lobby you connect to, not query result [0]"

A join occasionally connects to the wrong host or to a build-mismatched lobby, even though the pre-connect validation gates (protocol version, publish stamp) appear to pass. The failure is silent — no error, just unexplainable behavior after connecting.

A latent bug shape on the P2P join path: the validation gates (protocol version, build/publish stamp) ran against results[0] while the connect used the first open row, which can be a different lobby. A peer could connect to a lobby it never actually validated — a build-skew or wrong-host connect that no gate caught.

This happens because lobby query results can contain multiple lobbies, and the ordering is not guaranteed to be stable between the validation pass and the connect call.

Run the gates on the same candidate object the connect will use (not a sibling row):

// Wrong — validates one lobby, connects to another:
var gates = results[0];  // validate this
var target = results.FirstOrDefault(r => r.IsOpen);  // connect this (may differ!)

// Right — validate the exact candidate you connect to:
var target = results.FirstOrDefault(r => r.IsOpen);
if (target == null || !ValidateGates(target)) return;
Connect(target);

Additionally:

• Re-query fresh per attempt — do not reuse a stale query result across retries. This also feeds the poisoned-pair recovery (see steam-p2p-session-poisoned-pair): avoid the last-failed lobby id on the fresh query.
• Log the chosen candidate's lobby id + metadata age at connect time so a wrong-candidate connect is visible in the log.

By validating the exact lobby object used for the connect call, the pre-connect gates are guaranteed to check the actual target. A fresh query per attempt ensures the results reflect the current lobby state, and logging the candidate provides an audit trail when a connect goes wrong.