fix(tap): read oversized frames for local drop accounting

The Windows client reads TAP frames and then applies the same local safety path
used for malformed, jumbo, over-MTU, and forbidden remote-client traffic. The
read buffer was only one standard Ethernet frame long, which made an oversized
TAP frame more likely to fail at the device-read boundary before the client
could count and log the drop.

Keep the accepted Ethernet-frame limit unchanged, but make the TAP read buffer
large enough to receive oversized frames and let the existing safety checks
reject them in the normal path. Document the distinction in the TAP crate
summary.

Test Plan:
- cargo fmt --check
- cargo test -p lanparty-client-tap -p lanparty-client-win
- cargo check -p lanparty-client-tap --target x86_64-pc-windows-msvc
- cargo clippy -p lanparty-client-tap -p lanparty-client-win \
  --all-targets -- -D warnings
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- git diff --check
- git diff --cached --check

Refs: MVP TAP drop diagnostics

README.md

@@ -93,6 +93,7 @@ Windows TAP adapter boundary:
 - TAP `NetworkAddress` registry configuration for the tunnel MAC identity
 - `\\.\Global\{NetCfgInstanceId}.tap` device path construction
 - blocking Ethernet frame reads/writes through the TAP device handle
+- oversized TAP read buffering so jumbo frames can be counted and dropped
 - TAP driver IOCTL helpers for media status, adapter MAC, and MTU
 
 ### `lanparty-relay`