Before piping a simulator's live dump into a converter, check the converter's input contract on a real FIFO

Plan: avoid writing a huge intermediate dump by piping it straight from the simulator into a converter (simulator -> FIFO -> converter stdin).

Check first: many converters that accept a path don't really stream. They mmap the file, stat it for its size, seek back for a second pass, or pre-scan the header. Passing /dev/stdin or a FIFO path doesn't fix that: it fails, hangs, or silently reads a truncated input. Don't infer this from the code alone. Run a 30-second smoke: mkfifo, start the converter on the FIFO, then cat a small dump into it. Check that the output matches the file-input run, and look at peak RSS (it should stay bounded, not grow with input size) and at truncated-input behaviour (it should exit non-zero, not write a partial file that looks valid).

If it's mmap-only, you need a separate incremental front end around the existing codec. Treat that as a reviewed code change with its own content-equality gate, not a flag.

Cost framing: piping saves disk and wall time waiting for the file. It does not save converter CPU, and it can add backpressure stalls in the simulator. Measure the simulator's wall time and the converter's CPU separately, and label the pump's blocked-write time as a proxy, not a measurement of simulator stall.