fix(relay): filter remote IPv6 fragments

The relay now looks through ordinary IPv6 extension headers to catch remote
DHCPv6 server replies and Router Advertisements. IPv6 fragments are still an
evasion risk because later fragments may not contain the upper-layer ports or
ICMPv6 type that the relay safety policy checks.

For the MVP, make that boundary conservative: remote-client IPv6 fragments are
filtered before they can reach the physical LAN. LAN-origin fragments are still
allowed to flow back to remote clients, so this does not block ordinary LAN
traffic returning through the gateway. Add a dedicated diagnostics drop reason
so logs explain the policy clearly.

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

Refs: MVP relay L2 safety filters

README.md

@@ -102,9 +102,9 @@ Public relay binary and relay-owned room state:
 - live Ethernet datagram forwarding with no ingress reflection
 - 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, IPv4/IPv6
-  DHCP-server, and IPv6-RA frames, including frames behind ordinary IPv6
-  extension headers
+- L2 safety filters for invalid-source, jumbo, switch-control, remote IPv6
+  fragments, IPv4/IPv6 DHCP-server, and IPv6-RA frames, including frames 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