Before making split-and-overlap the default, time it against the plain monolithic run

A common optimisation is to split a produce-then-convert pipeline (simulate/dump, then convert) into N slices and overlap conversion with production. Measure three arms on an exclusive host, with medians and min..max: - A: monolithic produce, then convert; - B: slice, then convert; - C: slice with concurrent conversion. On a small workload (~1 s), C beat B on wall time (overlap works) but was still slower than A, and used ~23% more CPU than A, because each slice pays fixed setup and output-header costs. Don't conclude 'overlap helps' from C vs B alone; the baseline is A. Keep slicing opt-in until a larger workload shows C < A on both wall and CPU, and record the CPU cost, not just wall time. Also check that outputs still match a reference (hash maps) in every arm.