fix(client): prefer non-link-local TAP IPv4 diagnostics

Windows can report more than one unicast address on the TAP adapter. If an
APIPA address remains present next to the real LAN DHCP address, choosing the
first IPv4 address can make diagnostics warn about 169.254.x.x even though the
adapter already has a usable LAN address.

Prefer a non-link-local IPv4 address for TAP diagnostics, then fall back to any
IPv4 address, then to the first non-IPv4 address. This keeps the existing APIPA
warning when APIPA is the only IPv4 signal, but reports the real DHCP address
when Windows exposes both addresses.

README.md and TESTING.md now document that diagnostics prefer the real LAN IPv4
when several TAP addresses are visible.

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

Refs: PLAN.md client diagnostics; TESTING.md TAP IP verification

README.md

@@ -259,8 +259,9 @@ It prints and reports client diagnostics snapshots with relay reachability,
 LAN-gateway presence, route-pinning, QUIC datagram budget, relay RTT, TAP
 status/IP, broadcast frame flow, frame/datagram counters, and drops. The
 periodic diagnostics refresh the TAP unicast IP so DHCP results that arrive
-after bridging starts become visible in later status lines. Each snapshot also
-emits short user-facing lines such as relay/gateway connection status,
+after bridging starts become visible in later status lines, preferring a
+non-link-local IPv4 address when Windows reports several TAP addresses. Each
+snapshot also emits short user-facing lines such as relay/gateway connection status,
 relay-route and TAP readiness warnings, DHCP address presence, relay RTT, and
 broadcast-flow confirmation when those signals are observed. Malformed frames
 read from TAP, invalid or unauthorized source-MAC frames, L2 control-plane