fix(obs): warn on TAP link-local IPv4

IPv4 link-local on the TAP adapter means Windows self-assigned APIPA because
LAN DHCP did not complete through the tunnel. The previous user diagnostic
only said "TAP IP detected", which made a failed DHCP path look neutral
during MVP testing.

Return a full UserDiagnostic from TAP IP classification so IPv4 link-local
can be a warning while normal IPv4 still reports the received DHCP address.
Keep IPv6 link-local neutral because it is expected on many Windows
interfaces and is not evidence of LAN DHCP success or failure.

TESTING.md now tells the operator to troubleshoot 169.254.x.x like
`Waiting for TAP IP`.

Test Plan:
- cargo test -p lanparty-obs
- 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 diagnostics; TESTING.md MVP guide

TESTING.md

@@ -242,6 +242,10 @@ If the client says `Waiting for TAP IP`, DHCP is not making the full round trip.
 Check relay/gateway frame logs for broadcast traffic and check that the gateway
 is on wired Ethernet.
 
+If the client reports a TAP link-local address such as `169.254.x.x`, treat it
+the same way: Windows has self-assigned an address, but LAN DHCP did not
+complete through the tunnel.
+
 If startup fails with a TAP MAC mismatch, disable/enable the TAP adapter or
 reinstall TAP-Windows6 so Windows reloads the `NetworkAddress` value. Do not
 continue with a mismatched MAC.