fix(client): drop unsendable TAP frames locally

The Windows TAP pump used the same send helper as direct callers, so malformed,
jumbo, or over-budget TAP frames were reported as errors that stopped the
bridge. That is too brittle for the no-fragmentation MVP: local frames that
cannot fit the tunnel should be counted and dropped, while real QUIC send
failures should still surface as fatal.

Add a client send outcome that reports whether a frame was sent or locally
dropped. The existing send_ethernet API still returns an error for direct
callers when the outcome is a local drop. The live TAP pump uses the outcome API
so it can log the drop reason and keep forwarding later frames.

Document the new client behavior in the README.

Test Plan:
- cargo fmt --check
- git diff --check
- cargo test -p lanparty-client-core
- cargo test -p lanparty-client-win
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings

Attempted:
- cargo check -p lanparty-client-win --target x86_64-pc-windows-msvc
  (blocked by missing MSVC lib.exe on this Linux host)

Refs: PLAN.md

README.md

@@ -60,7 +60,8 @@ Platform-neutral remote client relay session:
 - welcome/reject handling with assigned peer id and effective TAP MTU
 - QUIC DATAGRAM support and negotiated datagram budget diagnostics
 - reliable relay control-event reads for peer lifecycle messages
-- Ethernet frame send/receive helpers over QUIC DATAGRAM with budget checks
+- Ethernet frame send/receive helpers over QUIC DATAGRAM with budget checks and
+  local drop outcomes for malformed or oversized sends
 - client tunnel statistics for frame/datagram rx/tx and drops
 - reliable client stats snapshot sends for relay diagnostics
 - best-effort graceful disconnect messages before QUIC close
@@ -223,7 +224,9 @@ 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, and broadcast-flow
-confirmation when those signals are observed.
+confirmation when those signals are observed. Malformed TAP frames, jumbo
+frames, and TAP frames whose encoded datagrams exceed the negotiated QUIC budget
+are counted and dropped before relay send without stopping 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