feat(ctrl): report gateway presence in welcome

ServerWelcome now carries an initial gateway_connected flag with serde defaulting
for older welcome payloads. The relay sets it from room admission state so a
gateway sees itself as connected, clients joining behind an existing gateway see
yes, and clients that arrive first see no.

The Windows client prints that handshake fact at startup. This does not replace
the later peer-event stream; it gives phase-1 diagnostics an immediate answer
for whether the relay already has a LAN gateway in the room.

Test Plan:
- cargo fmt --check
- cargo test -p lanparty-ctrl -p lanparty-relay -p lanparty-client-core \
  -p lanparty-client-win
- cargo clippy -p lanparty-ctrl -p lanparty-relay -p lanparty-client-core \
  -p lanparty-client-win --all-targets -- -D warnings
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- git diff --check

Refs: PLAN.md

README.md

@@ -29,6 +29,7 @@ Reliable control-plane schema shared by the QUIC stream handlers:
 
 - endpoint hello messages with role, room, MAC, and datagram budget
 - server welcome, reject, peer lifecycle, stats, and disconnect messages
+- initial room gateway-presence status in server welcomes
 - room-code, role/MAC, peer-id, and effective-MTU validation
 - length-prefixed JSON control frames for reliable QUIC streams
 
@@ -148,6 +149,8 @@ handshake, pins a host route for the relay IP on the current pre-TAP interface,
 verifies that the relay route still uses that pinned host route after TAP
 activation, and then bridges Ethernet frames between the relay and the first
 TAP-Windows6 adapter until shutdown.
+The startup status reports whether the relay already has a LAN gateway for the
+room.
 `--virtual-mac` can still override the stored identity for manual testing. On
 Windows it sets the TAP IP interface MTU to the relay-selected MTU, marks the
 TAP media connected, and reports the driver MAC/MTU before forwarding frames,