fix(relay): filter remote VLAN-tagged frames

The MVP bridge treats each remote player as a normal host on the LAN, not as a
trunk port. Allowing client-origin VLAN-tagged frames would let a remote client
send traffic outside the simple untagged Ethernet model, and could also hide
IPv4/IPv6 control traffic behind an outer VLAN EtherType that the existing
safety filters do not parse.

Filter 802.1Q, 802.1ad, and common QinQ-tagged frames from remote clients before
they can reach the physical LAN. LAN-origin tagged frames are still allowed back
toward clients so the gateway remains a transparent receiver for whatever the
local wired network emits. Add a dedicated drop reason so relay logs make the
policy clear.

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, remote IPv6
-  fragments, 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 VLAN
+  tags, 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