FsdbReader on 10 GB FSDBs: RSS grows with changes walked; use a fresh process per time range

Converting signals out of a 10 GB VCS FSDB with Verdi's FsdbReader (ffrAddToSignalList + ffrSetViewWindow/ffrResetViewWindow + ffrLoadSignals + traverse + ffrUnloadSignals per slice): process RSS keeps growing with the number of value changes traversed, even with many small view-window slices, malloc_trim, and unloading after every slice. One 512-bit signal with ~38 M changes reached 4.3 GB over the whole run, but 0.29 GB when the process handled only 1/8 of the time range. Retrying with more slices when RSS is over a cap does not help. What worked: split the job into (signal shard x time part) jobs, each in a fresh process (e.g. 8 time parts, 4-signal batches, 4 slices per part), run N at a time with a watchdog on RSS and host MemAvailable, and sum the per-part results per signal (a stream hash becomes the tuple of part hashes). Throughput at those safe settings was ~3.1 us per value change per process (about 60% reader load time), vs ~1.3 us with large batches on a 1.7 GB file. Related: fsdbdebug -top_n_var 0 <fsdb> lists only the stored (primary) signals with their value-change counts; the reader's tree also exposes computed signals and packed structs (whose members fsdbdebug lists as secondary), so count bytes per stored change, not per var.