feat(client): refresh TAP IP diagnostics

The Windows client sampled TAP diagnostics once when opening the adapter. That
can miss the useful DHCP result because the TAP interface may not receive a LAN
address until after frame bridging starts.

Keep the stable TAP diagnostics fields from startup, but retain the interface
identity and re-read the TAP unicast IP whenever the periodic diagnostics tick
prints and reports a snapshot. Later status lines can now show the DHCP address
that arrives after the tunnel is already moving traffic.

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

Refs: PLAN.md

README.md

@@ -191,7 +191,8 @@ adapter may need to be disabled/enabled or reinstalled before it reloads the
 configured `NetworkAddress`.
 It prints and reports client diagnostics snapshots with relay reachability,
 route-pinning, QUIC datagram budget, TAP status/IP, frame/datagram counters,
-and drops.
+and drops. The periodic diagnostics refresh the TAP unicast IP so DHCP results
+that arrive after bridging starts become visible in later status lines.
 Relay lifecycle events are logged as they arrive, including gateway joins and
 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