fix: a loaded recording is filtered into its buffer, not truncated

The loader pushed one slot per file row while the plan decimated by
eight, so a 10 M-row file overran the ring and only its last 4.19 s
survived -- a 20 s recording that read as a 4 s one. Each group of
`time_stride` rows is now averaged into one slot at the group's mean
stamp, as the packet path already does, and the load line reports
rows and decimation so a filtered file cannot be mistaken for a
truncated one.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/claude/verification.md

@@ -354,12 +354,27 @@ as distinct from the fault injection below, which exercises ingest:
 - **A waveform round-trips.** Export from a live run (`UDPSCOPE_EXPORT_MS` with
   `UDPSCOPE_EXPORT_PATH`, against the mock at 10 kS/s), then open that file with `--open` and an
   exit dump. The load must print
-  `[udpscope] waveform loaded: … signals=4 samples=20001 span=2.000000s rate=10000 time=[-2.000000..0.000000]`
+  `[udpscope] waveform loaded: … signals=4 samples=20001 rows=20001 decim=1 span=2.000000s rate=10000 time=[-2.000000..0.000000]`
   — **the same row count, column count, span and time range the export probe reported**
   (`rows=20001 cols=4 time=[-2.000000..0.000000]`) — and the dump must show `channels=4`,
   `frames=0 packets=0` (no acquisition) and, per channel,
   `20001 samples vs 20001 time slots … y=[-1.0000, 1.0000]`. A file that loads with fewer samples
   than it was written with, or with `NaN` slots, is the reader mis-slicing its records.
+- **A recording that does not fit its buffer is *filtered* into it, not truncated.** The case needs a
+  file bigger than the budget, which the mock cannot export in one window, so write one with NumPy —
+  the dtype is the exporter's own, `[('time','<f8'), ('abs_seconds','<f8'), (<signal>,'<f4'), …]` — and
+  open it against a small buffer:
+  ```bash
+  python3 -c "import numpy as np; n=1000000; t=-4.0+np.arange(n)/50000.0; \
+  a=np.zeros(n, dtype=[('time','<f8'),('abs_seconds','<f8'),('a','<f4'),('b','<f4'),('c','<f4'),('d','<f4')]); \
+  a['time']=t; a['abs_seconds']=1000.0+t; a['d']=np.linspace(-1,1,n); np.save('/tmp/long.npy', a)"
+  xvfb-run -a env UDPSCOPE_EXIT_AFTER_MS=4000 ./build/udpscope --open /tmp/long.npy --buffer-mb 1
+  ```
+  must read `samples=31250 rows=1000000 decim=32 span=19.999980s time=[-4.000000..15.999980]` and
+  `stored=31250 … published=31250` per channel — **the whole span, at a thirty-second of the rate**.
+  The ramp column is the assertion that the *head* is there: `y=[-0.999969, 0.999969]` is the file end
+  to end, where the defect this exists for reads a fraction of it. With every row pushed regardless of
+  the plan, this file arrived as its **last 0.9 s** and nothing in the log said so.
 - **A loaded file can be plotted.** `UDPSCOPE_PROBE_DROP_MS` drives the drop handler the way a drag
   from the signal panel does, on a file opened with `--open`: it must read
   `[drop-probe] signals=4 channels=4 rows=4 slots0=[sine|||]` — **`rows` equal to the column count**,