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

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")?