Two receive-path findings from the networking audit:
1. The anti-replay window (4096 seqs) silently re-tightened the "late ≠ lost"
fix: at 1 Gbps (~125k pkt/s) it spans only ~33 ms, so a Wi-Fi-retry-delayed
shard the reassembler's 120 ms loss window would still use was dropped HERE
first as "older than the window" — recreating the false-loss → recovery-IDR
churn the time-based loss window was built to kill, exactly on the high-rate
links punktfunk targets. Widened to 32768 (covers 120 ms up to ~270k pkt/s,
≈2 Gbps+); the bitmap costs 4 KiB per session and the replay-hiding bound
stays finite.
2. Every received datagram still paid one Vec allocation in the AES-GCM open
(and a to_vec on the plaintext probe path) — ~125k allocs/s of cross-thread
allocator churn at line rate, the same class of overhead that was the
documented single-core wall on the macOS receive path. New
`SessionCrypto::open_in_place` (mirror of seal_in_place; GCM verifies the
tag BEFORE decrypting, so a forged packet never yields plaintext) lets
`poll_frame` decrypt inside the recv ring and hand the reassembler a slice.
Byte-identical semantics, unit-tested against `open` incl. tamper/runt
cases; criterion entry added next to seal_in_place.
Tests: 94 core unit + loopback/c_abi suites green; clippy clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
enricobuehler
c7b8007ce7