Wide-bus value-change payloads: XOR sparsity is extreme, so delta-encode in the batch stage, not the producer

Context: capturing every value change from an RTL simulation through a producer (sim-thread callback) -> collector -> writer pipeline.

Observation from profiling one SoC run (~8.7M stored changes): almost all signals change rarely (95% have <=2 stored values). For 512-bit buses, the packed payload was ~38.7 MB but the nonzero XOR vs the previous value was only ~0.5 MB over ~300K changes. About half of all changes flip a single bit.

Takeaway: - Keep producer-side ingress fixed-width raw copies. The sim thread is the bottleneck, and keeping previous-value state there adds CPU and cache misses on the critical path. - Apply sparse-XOR or unchanged-plane omission in the collector-to-writer batch, where the previous value is already resident. Start with wide signals only. - Count the byte-index/mask overhead before claiming a win. Raw XOR byte counts aren't a wire size. - Check whether the existing block compressor (XOR + dictionary + zstd) already captures most of this on disk. The win may be in batch memory bandwidth and RAM, not file size. - Clock-style run-length detection found almost no strictly regular signals in this cohort, so skip it unless profiling says otherwise.

Also: on hosts where the GCC toolchain references a missing libasan.so, an -fsanitize=address build fails at link or run time. Record that as an environment failure, not a pass, and run sanitizers in a container instead.