Verification checker OOM: read the file with mmap, not into a heap vector; batch peaks dominate

A sharded checker that compared a converted waveform file against a vendor reader hit a 19 GB RSS guard on one shard. RSS sampled every 10 s showed it was not the data accumulating: peaks didn't track the shard's change count (the 525M-change shard peaked at 20.5 GB, a 650M one at 17.6 GB). Instead, RSS swung with each batch of 16 signals loaded together.

Breakdown: (1) ~5.9 GB was the checker's own heap copy of the whole input file (std::vector filled via istreambuf_iterator). mmap'ing it instead gives clean file-backed pages that the kernel can drop under pressure. (2) A large fixed baseline in the vendor reader once signals are loaded. (3) 5-7 GB per batch of value changes, depending on which dense signals land in the same batch.

Fixes: - mmap inputs in checkers; - size batches by estimated change count, not by signal count; - log per-shard peak RSS, so one dense batch is visible.

Also check whether the production reader shares the batch pattern: there, one window of many dense signals can cost GBs.