fix(client): drop malformed TAP frames without stopping

The Windows TAP reader used the validating read helper, so a malformed or runt
TAP frame would surface as a read error and stop the whole client bridge. The
client relay send path already has the right semantics for bad local frames: it
counts malformed, jumbo, and over-budget frames, reports the drop reason, and
keeps the bridge running.

Read raw TAP frames in the Windows pump and pass the bytes through
send_ethernet_with_outcome. Device read errors still stop the bridge, but frame
validation failures now follow the documented local-drop path instead of tearing
down the session.

Test Plan:
All cargo commands used these environment variables:
RUSTUP_HOME=/tmp/softlan-vpn-rustup
CARGO_HOME=/tmp/softlan-vpn-cargo

- cargo test -p lanparty-client-core connects_to_relay_control_stream_as_client
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- cargo check -p lanparty-client-tap --tests
  --target x86_64-pc-windows-gnu
- cargo check -p lanparty-client-tap --tests
  --target x86_64-pc-windows-msvc
- cargo check -p lanparty-client-route --tests
  --target x86_64-pc-windows-gnu
- cargo check -p lanparty-client-route --tests
  --target x86_64-pc-windows-msvc
- git diff --check

Known limitation: full lanparty-client-win Windows cross-check remains blocked
on this host by ring requiring x86_64-w64-mingw32-gcc for the GNU target.

Refs: PLAN.md better malformed-frame handling

README.md

@@ -247,10 +247,10 @@ periodic diagnostics refresh the TAP unicast IP so DHCP results that arrive
 after bridging starts become visible in later status lines. Each snapshot also
 emits short user-facing lines such as relay/gateway connection status,
 relay-route and TAP readiness warnings, DHCP address presence, relay RTT, and
-broadcast-flow confirmation when those signals are observed. Malformed TAP
-frames, jumbo frames, and TAP frames whose encoded datagrams exceed the
+broadcast-flow confirmation when those signals are observed. Malformed frames
+read from TAP, jumbo frames, and TAP frames whose encoded datagrams exceed the
 negotiated QUIC budget are counted and dropped before relay send without
-stopping the bridge.
+stopping the bridge; TAP device read/write errors still stop the bridge.
 Relay lifecycle events are logged as they arrive, including gateway joins and
 peer leaves. The client remembers peer identities from join and catch-up events
 so later leave logs can identify a disconnected LAN gateway or client MAC when

crates/lanparty-client-win/src/main.rs

@@ -1019,9 +1019,7 @@ fn read_and_relay_tap_frame(
     relay_io: &ClientRelayIo,
     buffer: &mut [u8],
 ) -> Result<()> {
-    let len = tap
-        .read_ethernet_frame(buffer)
-        .context("failed to read TAP Ethernet frame")?;
+    let len = tap.read_frame(buffer).context("failed to read TAP frame")?;
     match relay_io
         .send_ethernet_with_outcome(&buffer[..len])
         .context("failed to send TAP Ethernet frame to relay")?