fix(relay): detect IPv6 RAs behind extension headers

Remote clients must not be able to inject IPv6 Router Advertisements onto the
LAN. The relay already filtered direct ICMPv6 RA packets, but the check only
looked at the IPv6 base header's immediate next-header value. A client could
hide the ICMPv6 RA behind ordinary IPv6 extension headers and bypass that MVP
safety policy.

Walk the IPv6 extension-header chain for hop-by-hop, routing, destination
options, fragment, and AH headers before checking the ICMPv6 message type. This
keeps non-RA ICMPv6 traffic eligible for normal relay forwarding while closing
the obvious RA evasion path. Document the stronger relay safety boundary in the
README.

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

Refs: MVP relay L2 safety filters

README.md

@@ -103,7 +103,7 @@ Public relay binary and relay-owned room state:
 - per-peer egress budget checks against the negotiated datagram size
 - reliable `PeerJoined`/`PeerLeft` notifications to existing room peers
 - L2 safety filters for invalid-source, jumbo, switch-control, DHCP-server,
-  and IPv6-RA frames
+  and IPv6-RA frames, including RAs behind ordinary IPv6 extension headers
 - client broadcast/multicast, unknown-unicast, and total bandwidth limiting
 - malformed peer datagram disconnect threshold
 - peer stats control events retained for relay diagnostics