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>

README.md

@@ -672,6 +672,17 @@ from the file: a `.npy` written by `write_npy()` is a structured array whose *dt
 Only `.npy` is read: it is the format the item asked for and the one that carries names. A `.csv`
 export is for other tools.
 
+**A recording longer than the buffer can hold at its own rate is resampled, never cut short.** The
+file is pushed into the same ring a stream fills, and that ring is sized by `--buffer-mb`: 20 s of ten
+channels at 500 kS/s is 480 MB of rings, which a 200 MB buffer cannot hold. The loader therefore reads
+the decimation the plan chose and pushes one stored sample per group of file rows, carrying the
+group's **mean** — the same anti-aliased filter the live ingest applies, so a long event opens as the
+whole recording at a lower sample rate instead of as a fraction of itself. It used to push every row
+regardless, which overran the ring and left the file as **its own tail**: a 20 s event opened showing
+only its last 4 s, with a correct-looking 20 s header line above it. The load line now names both
+numbers, `samples=31250 rows=1000000 decim=32`, so what is on screen is never in doubt; give the run a
+larger `--buffer-mb` (the source's configuration carries one) to see such a file sample for sample.
+
 ## Named configurations
 
 What you arranged is remembered per data source, and a source can hold **several named