fix(relay): filter remote DHCPv6 server replies

The MVP safety policy says remote clients must not inject DHCP server replies
onto the LAN. The relay enforced that for IPv4 DHCP, but DHCPv6 uses UDP
547 -> 546 over IPv6 and was not covered by the existing check.

Split the DHCP server-reply predicate into IPv4 and IPv6 paths. The IPv6 path
reuses the extension-header walker so server replies hidden behind ordinary IPv6
extension headers are still treated as unsafe. Keep client DHCPv6 requests
allowed, and continue allowing LAN-origin DHCPv6 replies to flow back to remote
clients.

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

@@ -102,8 +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, DHCP-server,
-  and IPv6-RA frames, including RAs behind ordinary IPv6 extension headers
+- L2 safety filters for invalid-source, jumbo, switch-control, 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