fix: a claimed gap must be corroborated before it is believed, and its hole must fit

The user's real host reported "connected and live" with one missing-data band over the whole window
and no trace in it. The counter is the only thing that claims a packet existed, and a reservation
was booked on its word alone: a source whose DATA counter counts samples, or frames of an inner
layer, advances by more than 1 per datagram, the client cannot check that claim (it has no clock of
its own to compare against), so it holds each packet, saturates its reorder ring, delivers it in
order and reports the skipped counters as lost. Every frame therefore reported a phantom gap, and
`reserve_hole()` wrote `lost * batch_` NaN samples with no bound but the 256-PACKET cap -- the
sample form of that rule ("the number to weigh against the ring is 256 * batch_, not the 256") was
never implemented. With relative time on -- which that session carries -- each phantom gap is
materialised as NaN slots by construction: the window filled with reservations, there was never
anything missing to repair them, and the gaps also stretched the relative clock, which is why the
status bar read live at ten times the true rate.

`Acquisition::gap_plausible()` now gates every reservation on two independent tests: the arrival
clock must corroborate the claim (that many missing packets would take that many frame intervals;
deliberately permissive, because a false refusal costs a shading and never data), and the ring must
be able to hold the hole. The verdict is taken before the stamps, and relative mode's slot advance
is skipped with it, since the advance and the reservation are the same claim. Refusals are counted
in `StreamStats::gaps_refused` and said once per connection with the numbers, naming the wire shape
they describe.

tools/mock_udpstreamer.py gains `--counter-step N`: a counter that is not a packet counter on an
intact link, which is the one shape the mock could not produce and the shape the report came from.

Verified in both directions. A counter stepping 1000 per datagram reads `holes=0 hole_slots=0
backfilled=0` with the traces present (3 traces, 1.4 M samples) against 7.9 M claimed gaps, and the
warning above names the cause. Every other packet withheld -- a real loss -- still reads
`holes=3579`, so genuine gaps are still reserved: a fix that stopped believing real losses would
have traded one wrong picture for another. The user's control read as "the math channel is the
problem" and was confounded -- disabling it is a structural change, which rebuilds the buffer and
clears the accumulated NaN.

README.md

@@ -554,6 +554,17 @@ missing shades solidly, even if all but one slot are already repaired. And the t
 yet configurable; the preferences dialog in `todo.md` is where that would land. Do not use a
 command-line flag for either; none exists.
 
+**The counter is a claim, and the wire is checked against it.** A gap is only booked when the
+arrival times corroborate it: `lost` packets would have taken that many packet intervals to
+arrive, and a claim of less than half that is refused, as is a hole bigger than the ring could
+hold. The status bar's `gaps` counts what the *stream* says either way; the refused ones are
+counted separately and said once on stderr. That matters for one kind of source: a device whose
+counter counts something other than packets — samples, or frames of an inner layer — reports a
+forward jump on every datagram. Believing it reserved a NaN run per packet, which on an intact
+link reads as one missing-data band over the whole window with the samples washed out and nothing
+lost to backfill it, while the status bar says `live`. The samples are now kept and the gap shows
+as the x discontinuity it is.
+
 **`--relative-time` makes the x axis follow the sample count and the declared rate**, rather than
 the stream's own clock. The packet counter says exactly how many samples each gap spans, so a
 reserved hole is a precise arithmetic range. In stream mode the same hole is estimated from the