Budgeting compression CPU in live trace capture: express it as a share of simulation CPU, and count background threads

A compression setting that's too expensive for offline conversion (e.g. +30-90% write CPU) can be affordable during live simulation, because there it only scales the dumping share of the run. If dumping adds ~3% to simulation CPU, even +90% on that share is ~5-6% of the run. Set the budget relative to a competitor on the same run: e.g. our dumping overhead is at most 2-3x the native dumper's, and a small fraction of total sim CPU. Judge it on CPU-seconds of the whole process (including flusher or compression threads), not wall time alone. A background thread looks free on one simulation, but in a regression running many sims in parallel on one machine, its core is taken from another sim. Don't extrapolate from conversion benchmarks: live capture also pays for the tap or DPI calls and their evaluation, so add one 'aggressive settings' arm to the pilot and measure the ceiling directly, with a profile of the sim and writer threads.