fix(tunnel): enforce negotiated TAP MTU

The MVP tunnel negotiates an effective TAP MTU and configures the Windows TAP IP
interface to that value, but the forwarding path only rejected frames that were
standard-Ethernet jumbo frames or exceeded the QUIC datagram budget. A frame
could therefore be larger than the negotiated TAP MTU while still fitting inside
the QUIC datagram budget.

Make the TAP-MTU frame limit an explicit shared protocol helper and enforce it
at every data-path boundary: Windows client send/receive, Linux gateway
send/receive, and relay forwarding. Such frames now produce TapMtuExceeded in
logs and counters instead of being forwarded until a later layer drops or
accepts them implicitly.

This keeps the no-fragmentation contract honest: one Ethernet frame still maps
to one QUIC datagram, but only if that frame also fits the room's negotiated TAP
MTU.

Test Plan:
- cargo fmt --check
- cargo test -p lanparty-proto tap_mtu
- cargo test -p lanparty-client-core connects_to_relay_control_stream_as_client
- cargo test -p lanparty-gateway connects_to_relay_control_stream_as_gateway
- cargo test -p lanparty-relay drops_frames_above_effective_tap_mtu
- cargo test -p lanparty-relay rate_limits_client_total_bandwidth_after_burst
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- cargo build --release -p lanparty-relay -p lanparty-gateway
- git diff --check
- git diff --cached --check

Refs: MVP no-fragmentation tunnel MTU contract

README.md

@@ -103,6 +103,7 @@ Public relay binary and relay-owned room state:
 - one gateway per room, duplicate client MAC rejection, and room limits
 - stable effective room MTU chosen before Ethernet datagrams flow
 - live Ethernet datagram forwarding with no ingress reflection
+- forwarding drops for Ethernet frames above the negotiated TAP MTU
 - 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 VLAN
@@ -185,14 +186,15 @@ frames between the relay and wired LAN until shutdown. It captures whole LAN
 frames up to the
 overlay payload-length ceiling before deciding whether they fit the tunnel. It
 never fragments Ethernet frames; LAN frames with invalid source MACs, L2
-control-plane traffic, jumbo frames, or encoded datagrams exceeding the
-negotiated QUIC budget are counted, dropped, and logged locally instead of
-stopping the bridge or consuming relay bandwidth. Remote frames received from
+control-plane traffic, jumbo frames, frames above the negotiated TAP MTU, or
+encoded datagrams exceeding the negotiated QUIC budget are counted, dropped,
+and logged locally instead of stopping the bridge or consuming relay bandwidth.
+Remote frames received from
 the relay are safety-checked again before LAN injection and must use the
 announced virtual MAC for their source peer, so invalid-source, forged-source,
 L2 control-plane, remote VLAN, DHCP-server, IPv6 Router Advertisement, IPv6
-fragment, and jumbo frames cannot cross the gateway's final physical-LAN
-boundary even if they reached the gateway over QUIC.
+fragment, jumbo, and over-TAP-MTU frames cannot cross the gateway's final
+physical-LAN boundary even if they reached the gateway over QUIC.
 `--relay` accepts a DNS name or socket address; bare hosts default to UDP/443.
 The gateway rejects Linux interfaces that sysfs identifies as Wi-Fi, and rejects
 wired interfaces whose sysfs carrier state reports no link; managed wireless
@@ -275,11 +277,12 @@ broadcast-flow confirmation. One-way broadcast diagnostics distinguish frames
 sent toward the LAN from broadcast frames received back from the LAN. Malformed frames
 read from TAP, invalid or unauthorized source-MAC frames, L2 control-plane
 traffic, remote VLAN tags, DHCP server replies, IPv6 Router Advertisements, IPv6
-fragments, jumbo frames, and TAP frames whose encoded datagrams exceed the
-negotiated QUIC budget are counted and dropped before relay send without
-stopping the bridge. Relayed LAN frames are also safety-checked before TAP
-writes, so switch-control traffic, invalid-source frames, and jumbo frames stay
-out of the Windows adapter even if they reached the client over QUIC.
+fragments, jumbo frames, frames above the negotiated TAP MTU, and TAP frames
+whose encoded datagrams exceed the negotiated QUIC budget are counted and
+dropped before relay send without stopping the bridge. Relayed LAN frames are
+also safety-checked before TAP writes, so switch-control traffic,
+invalid-source frames, jumbo frames, and over-TAP-MTU frames stay out of the
+Windows adapter even if they reached the client over QUIC.
 Misdirected unicast frames not addressed to the client's virtual MAC are also
 counted and skipped; accepted TAP-to-relay and relay-to-TAP frames are logged
 with direction, peer id, MACs, ethertype/length, frame length, action, and drop