FsdbReader window reads: most of the cost is computing secondary (non-dumped) signals in ffrLoadSignals

Measured on a ~59 MB VCS FSDB (RISC-V core scope, 7k signals of which ~57% are reader-computed secondaries). Reader config: ffrSetLoadNavDBOnlyOnce, signal list added once, then per window ffrSetViewWindow/ffrResetViewWindow + ffrLoadSignals + ffrGotoXTag(start) + ffrGetXTagVCSeqNum walk. - 50 signals, 2000-cycle windows: with 30 secondaries in the set, a window costs ~180 ms wall and ~430 ms CPU, almost all inside ffrLoadSignals (up to 11 threads). - The same method on 50 stored (primary) signals: ~15 ms wall, ~30 ms CPU per window. - So comparing a waveform cache against FSDB on mixed signal sets mostly measures FSDB deriving secondaries. Report stored-only and mixed sets separately. - Report CPU (getrusage, all threads) next to wall. The reader is multi-threaded, so wall alone flatters it.

For a block-compressed cache (16k changes per zstd block), short-window reads are dominated by decoding whole blocks: ~7M rows decoded for ~0.2M changes in the windows. Keyframe chunks (an independently decodable 4096-row chunk with a seek table) on every signal cut window CPU 1.9-2.5x, at ~+27% file size. Restricting keyframes to wide signals (e.g. >= 64 bits) helped little, because most busy signals are narrow.