feat(client): identify lifecycle leave events

The relay now sends enough PeerJoined events for the client to learn the peers
already in the room, but the client was still formatting PeerLeft with only the
bare peer id. That made a gateway disconnect look the same as any other peer
leaving.

Keep a small in-memory peer map in the control-event logger. PeerJoined records
or refreshes the peer identity, and PeerLeft removes it before formatting the
message. Unknown leaves still use the generic fallback, so out-of-order or
missed events remain understandable.

Test Plan:
- cargo fmt --check
- cargo test -p lanparty-client-win formats_relay_lifecycle_events \
  -- --nocapture
- cargo test -p lanparty-client-win
- cargo clippy -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

@@ -167,4 +167,6 @@ before bridging if the driver-reported MAC does not match the tunnel identity.
 It prints client diagnostics snapshots with relay reachability, route-pinning,
 QUIC datagram budget, TAP status/IP, frame/datagram counters, and drops.
 Relay lifecycle events are logged as they arrive, including gateway joins and
-peer leaves.
+peer leaves. The client remembers peer identities from join and catch-up events
+so later leave logs can identify a disconnected LAN gateway or client MAC when
+that peer was known.