Verdi FsdbReader slow loads: secondary (reconstructed) signals and a per-load nav-DB floor

Profiling FsdbReader (W-2024.09) whole-signal loads with eu-stack (libnffr has a symbol table) showed two costs that are neither IO nor zlib. (1) Undumped 'secondary' signals (port aliases, interface members, combinational wires) are rebuilt by re-simulating a gate/bytecode network over the dumped primaries (MTComputeSecondaryVarFullLoad > FHVpd FHRGate evaluate). A port alias of a clock loaded 16x slower than the clock itself. The public API has no is-secondary query, and FSDB_ENV_DBG_SEG_INFO=1 prints which internal idcodes a load touches. (2) For primaries, every ffrLoadSignals re-inflates the navigation DB (LoadNavDB2 > hug_inflate). That costs ~110 ms on a 1.7 GB file and ~650 ms on 10 GB, whatever the ffrSetViewWindow size. Batch primaries into one signal list (2.9x less CPU for 8 signals) instead of splitting them into time pieces. Secondaries have no such floor and scale linearly with the window. Separate processes scale near-linearly, while in-process FFR_MT_THREAD_COUNT threads cut wall time but use 1.4-1.8x the CPU. Values decode lazily in ffrGetVC (DecompressBCNABVC), not in ffrLoadSignals.