feat(net): accept relay hostnames

PLAN.md describes the first client flow as entering a relay domain and room
code, but the client and gateway CLIs only accepted socket-address literals.
Add a small shared RelayEndpoint parser so bare hosts default to UDP/443 while
IP literals and explicit host:port values stay supported.

The runtime configs still store resolved SocketAddr values. That keeps the
Windows route-pinning path on a concrete relay IP before TAP activation while
avoiding duplicated endpoint grammar between client and gateway. The relay
listen config reuses the same default port constant so UDP/443 has one source.

README examples now use lanparty-relay.local and document the shared endpoint
syntax.

Test Plan:
- cargo fmt --check
- cargo test -p lanparty-net
- cargo test -p lanparty-client-win \
  accepts_relay_domain_with_default_port -- --nocapture
- cargo test -p lanparty-gateway \
  accepts_iface_alias_for_gateway_interface -- --nocapture
- cargo test -p lanparty-net -p lanparty-client-win -p lanparty-gateway
- cargo clippy -p lanparty-net -p lanparty-client-win -p lanparty-gateway \
  --all-targets -- -D warnings
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- git diff --check

Refs: PLAN.md

README.md

@@ -6,6 +6,7 @@ Monorepo for a Layer 2 over QUIC LAN party bridge.
 
 - `lanparty-proto`: shared frame format, MAC validation, MTU helpers.
 - `lanparty-ctrl`: control-plane messages (join/hello/role/version).
+- `lanparty-net`: shared relay endpoint parsing and resolution.
 - `lanparty-obs`: shared diagnostics/logging event models.
 - `lanparty-client-core`: platform-agnostic client session state.
 - `lanparty-client-route`: Windows relay-route inspection.
@@ -41,6 +42,14 @@ Shared diagnostics and structured logging vocabulary:
 - tunnel counters shared by control messages and runtime diagnostics
 - client connectivity/TAP diagnostics and user-facing status messages
 
+### `lanparty-net`
+
+Shared network address handling for tunnel binaries:
+
+- relay DNS name, IP literal, and socket-address parsing
+- UDP/443 default for bare relay hosts
+- relay address resolution before tunnel interface activation
+
 ### `lanparty-client-core`
 
 Platform-neutral remote client relay session:
@@ -139,7 +148,7 @@ and the LAN gateway.
 
 ```bash
 cargo run -p lanparty-gateway -- \
-  --relay 203.0.113.10:443 \
+  --relay lanparty-relay.local \
   --server-name lanparty-relay.local \
   --relay-ca-cert relay-cert.der \
   --room ROOM1 \
@@ -149,7 +158,8 @@ cargo run -p lanparty-gateway -- \
 The gateway connects to the relay as `role = gateway`, completes the
 control-stream hello/welcome handshake, opens an AF_PACKET socket on the LAN
 interface with promiscuous packet membership, and bridges Ethernet frames
-between the relay and wired LAN until shutdown. It tracks remote-client source
+between the relay and wired LAN until shutdown. `--relay` accepts a DNS name or
+socket address; bare hosts default to UDP/443. It tracks remote-client source
 MACs seen from relay traffic and periodically emits small CAM refresh frames so
 the physical switch keeps those MACs associated with the gateway port. Gateway
 frame logs include direction, peer id when present, MACs, ethertype/length,
@@ -163,7 +173,7 @@ control message before closing QUIC so the relay can report the intended reason.
 
 ```bash
 cargo run -p lanparty-client-win -- \
-  --relay 203.0.113.10:443 \
+  --relay lanparty-relay.local \
   --server-name lanparty-relay.local \
   --relay-ca-cert relay-cert.der \
   --room ROOM1
@@ -171,11 +181,13 @@ cargo run -p lanparty-client-win -- \
 
 The Windows client binary currently connects to the relay as `role = client`
 with a generated locally administered virtual MAC persisted in
-`lanparty-client-identity.json`, completes the control-stream hello/welcome
-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. Before opening the adapter, it writes the
+`lanparty-client-identity.json`, resolves the relay DNS name before TAP
+activation, completes the control-stream hello/welcome handshake, pins a host
+route for the resolved 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. `--relay` accepts a DNS name or socket address; bare hosts
+default to UDP/443. Before opening the adapter, it writes the
 generated tunnel MAC to the TAP driver's `NetworkAddress` registry setting.
 The startup status reports whether the relay already has a LAN gateway for the
 room.