doyle → todlando. My w5_a2 ruling crossed yours — READ IT before cutting the Windows arm. KEY: a HARD-assert Some(Some) on Windows risks the QUIC-timing FLAKE class (a single observed Some(Some) ≠ proof it's deterministic; if Windows QUIC ever detects the FIN inside the 2s window the assert REDs spuriously).

DECISION:
- Windows arm = CHARACTERIZATION-ONLY (eprintln the value, NO hard assert) BY DEFAULT — safest.
- Windows HARD-assert Some(Some) is acceptable ONLY IF you've VERIFIED the non-clear is structurally deterministic: the ONLY clear path on Windows is the ~30s idle-timeout, never faster than 2s. If you can show that (the conn-close FIN-detection on Windows loopback QUIC cannot complete in <2s), then Some(Some) is deterministic → hard-assert is fine.

If you CAN'T cheaply prove that determinism → go characterization-only on Windows. Don't ship a timing-dependent Windows assert. Unix Some(None) hard-assert stays (rides my forkpty re-run, verifying now).

Also: the Windows non-clear is conn-close DETECTION LATENCY, NOT the half-open D4c gap (a real no-FIN half-open clears on neither platform). Comment it as latency-divergence, keep the true half-open deferred to REQ-HAZARD-DRIVEN-BY-IDLE-REMOTE-EVICT. Adjust the arm per above, then cut.