Benchmarking: 'warm' multi-read loops and 'cold' first reads measure different work

When a read benchmark reports cold = a single read after dropping the page cache in a fresh process, and warm = one process doing N reads with the cache populated, the two rows aren't the same operation at two cache states. Before explaining a warm loss, pull per-run CPU time next to wall time: if CPU ~= wall, the gap is decode work (format layout / codec choice), not I/O, and cache tricks won't fix it. Also check whether the memory metric is PSS: PSS counts the file pages the reader has mapped, so a reader that mmaps the file looks heavier than one using read() buffers, even when it allocates less itself. Report anon/private memory separately before claiming a memory win. Last, check whether the harness does any hashing or verification inside the timer; that cost scales with the number of signals and can make a format look slower.