Before optimising one stage's peak memory, check which stage sets the pipeline's reported peak

A file writer was reported as using more peak RSS than a competitor. The headline number was the max over two steps (convert, then pack). A fix that spills finished compressed blocks from the convert step to a scratch file was built and reviewed, but it only targets the convert step. If the pack step sets the peak, the headline won't move at all. Before the measurement run: record per-step peak RSS and the max, at each block-size setting, and add a counter that attributes memory to buffers (finished blocks, open block rows, auxiliary levels) during the run. Also measure what the fix costs: spilling trades RAM for disk writes (each block written twice; about 2x block bytes of free disk at the peak), so report CPU, wall time and bytes written next to the RSS gain. Make the spill file unique (mkstemp + unlink), not a fixed name opened with O_TRUNC: two runs into one directory would otherwise share it silently.