FrameSorter.push overlap loop is O(n²) under heavy out-of-order reordering

[endel]

Context

Follow-up from PR #23 review (merged in 5d9c626).

FrameSorter.push in src/quic/stream.zig has a fast path for sequential appends (effective_offset >= highest_buffered), which covers the dominant bulk-receive case in O(1). When that fast path misses, it falls into a while (true) overlap-resolution loop whose inner body scans the full chunks map (keys()/values()) once per overlapping chunk handled.

Issue

For a receive stream with many small out-of-order chunks buffered simultaneously (pathological reordering or an adversarial sender fragmenting at shifting boundaries), each push can do O(n) scans and the loop can run O(n) times → O(n²) per push. The chunk map is bounded, so this is not unbounded, but it is a latent throughput cliff under heavy reordering.

Severity

Minor / latent. The common in-order path is unaffected (fast path). Only triggers under sustained out-of-order delivery with many coexisting gaps.

Possible directions

• Maintain chunks in offset order (or an interval tree) so overlap resolution is a localized neighbor lookup instead of a full scan.
• Cap the overlap loop work and fall back to a coarser merge when degenerate.

No action needed unless profiling under reordering shows it; filing so it is not lost.