fix(stats): reject stale and discontinuous rolling counter baselines

crates/irtt-stats/README.md

@@ -39,25 +39,37 @@ Reading a snapshot does not advance time. Use count-based rolling storage for a
 hard bound on retained events. The memory estimate excludes time-window storage.
 
 Rolling directional loss uses the increase in the highest observed server
-receive count across the retained packet events in arrival order. Upstream loss
-is window sends minus that increase; downstream loss is the increase minus all
-window replies, including duplicates and untracked late replies, as in cumulative
-accounting. The baseline is the highest count observed before the first retained
-packet event, or zero if no earlier packet events existed. Each retained event
-keeps this prior position, so eviction cannot erase a known baseline. Reordered
-counts do not move the observation backwards; only matched unique replies supply
-counter observations, regardless of the late-reply timing policy.
+receive count within one observation segment across the retained packet events
+in arrival order. Upstream loss is window sends minus that increase; downstream
+loss is the increase minus all window replies, including duplicates and untracked
+late replies, as in cumulative accounting. The baseline must be supplied by the
+packet event immediately before
+the first retained packet event, or is zero if no earlier packet events existed.
+It must also equal the highest count observed in that segment. Intervening sends
+or replies without a current count make an older baseline stale: its next increase
+may cover packets outside the window. Each retained event keeps the count's observation
+ordinal, so eviction cannot erase this distinction. Reordered lower counts do not
+refresh the baseline; only matched unique replies supply counter observations,
+regardless of the late-reply timing policy.
 
 Both directional packet estimates are `None` if the baseline or endpoint is
-unknown, or if time filtering excludes a packet event between retained packet
-events. Their percentage fields use the existing unavailable value of `0.0`.
-Loss/warning events do not affect this interval. A boundary between a send and
-its reply can still produce signed estimates, and outstanding sends retain the
-existing provisional-loss interpretation. These are changes in observed
-accounting, not exact network transit loss for probes sent in a wall-clock period.
+unknown or stale, or if time filtering excludes a packet event between retained
+packet events. Their percentage fields use the existing unavailable value of `0.0`.
+Loss/warning events do not affect this interval. Signed estimates remain possible
+when server counts exceed local expectations or extra replies arrive, and
+outstanding sends retain the existing provisional-loss interpretation. These are
+changes in observed accounting, not exact network transit loss for probes sent
+in a wall-clock period.
 Raw `server_packets_received`, ordinary packet counts, and cumulative loss retain
 their existing meanings.
 
+A counter jump of at least half the 32-bit range is ambiguous between counter
+wrap and a very old reordered reply from the other side of a wrap. It starts a
+new observation segment; windows crossing the discontinuity have no directional
+estimate. Later windows can recover using a fresh baseline within that segment.
+The collector does not infer an epoch from incomplete arrival history. Smaller
+regressions retain the existing maximum-count interpretation for reordered replies.
+
 Exact snapshots sort a temporary copy of each metric's retained samples, adding
 O(n) scratch memory and O(n log n) computation for that metric. The retention
 estimate is not peak snapshot or allocator accounting.