Fewer bytes copied is not fewer CPU-seconds: measure delta/sparse transport end to end

A common optimisation for simulation-time capture (DPI/VPI callbacks feeding a writer thread) is to send only changed members of a grouped snapshot instead of the whole snapshot. In one measured case it cut queued value bytes by ~71% and total copy writes by ~55%, with byte-identical output files, yet total process CPU went UP by ~0.7% (3/3 paired repeats, disjoint ranges). The per-call comparison against a cached copy, plus mask bookkeeping, cost more than the memcpy it avoided, because the snapshots were small and already cache-resident.

Lessons: - Report whole-process CPU (user+sys of all threads) and wall vs a same-binary 'dumping off' baseline, not byte-traffic counters. - Also report the cost of merely building with capture hooks (plain build vs hook build with capture off); it can exceed the dump overhead itself. - Bound the possible gain first: if the whole copy path is ~2-3% of sim CPU, a delta scheme can only win that much. - Keep such modes opt-in until a timed run shows they're at least neutral; time each sub-optimisation (SIMD compare, set-bit iteration) separately against the same binary.