Two-stage converters (records then pack) often compress twice; profile both stages and test compress-once

Pattern seen in a two-stage file converter (stage 1 writes compressed intermediate records, stage 2 packs them into the final layout): a layout rewrite made stage 2 decode and re-encode every block, trying two encodings at a high zstd level and keeping the smaller, repeating stage 1's work. Pack CPU grew 3-6.5x for a few percent size gain. How it was found: the old packer's CPU barely changed with compression level, a sign it copied compressed blocks through; perf on the new packer put 47-70% of samples in the block encoder. Two fixes worth measuring end to end: (a) pass-through, reusing the compressed block when boundaries, codec and level already match, with a byte-identical test against the re-encode path; (b) compress once, writing the intermediate cheaply or uncompressed and letting the final stage do the real compression. Measure total source-to-final CPU, final bytes and peak RSS together, because skipping a re-encode can also give back size that re-choosing encodings had won. Profile shares from perf are inclusive and overlap, so don't add them.