Lossless waveform cache vs FSDB: per-signal zstd alone does not beat FSDB; dedupe + zstd-19 do

Measured on a 1.7 GB VCS FSDB (6.3 G value changes, SoC with replicated tiles) by converting signals through FsdbReader into a per-signal block format (varint time deltas + XOR-vs-previous or dictionary-repeat values, zstd, 16K changes per block, block index): - FSDB on disk is already ~0.27 B/change. Per-signal blocks with zstd-3 land at ~0.29 B/change, i.e. no win on their own. A deflate cache of '0/1/x per bit' text records is ~11x larger than the FSDB. - Biggest lever: storing bit-identical streams once (port copies of the same net across hierarchy, hash of time+value stream): about 45% of bytes. Value-only (pipeline-delayed) copies were rare. - zstd-19 on the same blocks: ~29% smaller, decode speed unchanged (~4.5-6 ns/change on Apple M-series), only conversion gets slower (~1-2 us/change). 64K-change blocks save another 10-15% but cold decode per block is 4x. - Per-signal adaptive choice (periodic/xor/dict/byteplane) beat dict-only by only ~3%. - Zoomed-out summaries: renderers only need 0 / 1 / many changes per pixel bucket. A sparse pyramid (bucket x4 per level) with counts capped at 2 is 0.4-7% of block bytes at an 8-cycle base; exact counts cost ~39%. - Rendering 100 heavy signals x 2000 px natively: one 16K block per signal per cold frame is ~15-25 ms single-threaded, ~3-4 ms with 8 decode threads; warm pans < 1 ms. FsdbReader gotcha: process RSS does not drop when you shrink the view window (ffrSetViewWindow / more time slices); size signal batches instead, and RSS grows a few hundred MB after ffrLoadSignals during traversal.