Fix various issues with matchmaking lobbies

[Liparakis]

What changed

1. MMS start-punch messages now include server time

The MMS server now sends serverTimeMs alongside startTimeMs in start_punch.

Client and host both record observed server-to-local clock offset and use that estimate when waiting for the coordinated punch start time.

Why:

• previously both sides assumed local clock ~= server clock
• if either machine clock drifted, punch packets could start too early or too late
• using MMS server time gives both sides a shared reference point

2. Host discovery can start immediately after lobby creation

The host now stores the initial discovery token returned by MMS and can start refreshing its UDP mapping as soon as the live server socket exists.

Why:

• previously MMS often did not learn the host's current external port until a join was already in progress
• that adds avoidable latency and increases the chance that the first join attempt races the mapping refresh
• priming the mapping on startup should make the first join more reliable

3. Steam lobbies are no longer advertised as ready too early

Steam lobby creation is now split into two phases:

1. create the native Steam lobby
2. wait for the host transport to come up, then finalize the lobby

During the gap, the lobby is marked not joinable and rich presence does not expose a connect target yet. After the host is actually ready, the lobby becomes joinable and public Steam lobbies are registered with MMS for browser visibility.

Why:

• previously a Steam lobby could expose a join path before the host was listening
• that creates misleading "Join Game" availability and early join failures
• the new sequence aligns Steam visibility with actual host readiness

4. Steam lobby join from MMS now uses Steam's native join flow

When MMS returns a Steam lobby entry, the client now parses the Steam lobby ID and calls SteamManager.JoinLobby(...) instead of treating the Steam lobby ID as a direct transport address.

Why:

• that path is more coherent with the rest of the Steam integration
• the actual transport connection should start after Steam confirms lobby join and ownership data is available

5. Matchmaking join UI is hardened against duplicate attempts

The lobby connect button now tracks whether a matchmaking join is already in progress and resets correctly on failure paths and retry handling.

Why:

• repeated button presses could overlap multiple join attempts

6. Same-PC matchmaking joins now route through loopback

When MMS returns a LAN fast-path endpoint and that endpoint belongs to one of the local machine's own interfaces, the client now canonicalizes the join target to 127.0.0.1:<actual host port> instead of trying to connect back through the machine's LAN address.

Why:

• matchmaking hosts do not always bind to the default port; a local instance can end up on an ephemeral port
• same-PC joins are a weirder case than ordinary LAN joins and should use loopback explicitly
• routing two local game instances through localhost is more deterministic than relying on local NIC self-routing

[Extremelyd1]

Looks good, thanks Liparakis!