FST benchmark traps: repack-on-close inflates open cost, and contended write runs skew CPU ratios

Two traps when comparing a new waveform format against FST at its smallest setting (zlib + repack on close). (1) Open time: a repacked FST must decompress the whole file before reading, so its open is far slower than FST's fastest-open setting (lz4, no repack). A 100x+ open ratio against the repacked file shrank to about 1.3x against lz4 without repack. Compare each metric against FST's best setting for that metric, or quote both. (2) Write CPU: if some write reps ran with many jobs at once, contention can inflate formats unequally (in one run FST about 30%, the new format about 7%), flipping a 16% loss into an apparent 6% win. Use only serial-control rows for write CPU, and never mix serial rows for one format with contended rows for another. Also: libfst value-at-time calls load a whole time block per call, so random-time single-signal point ratios mostly measure that per-call cost; label them as scattered single-signal points.