FSDB reader API on a file still being written: primaries AND computed signals load, ffrSync refreshes, reads are exact prefixes

Follow-up to a test that read a growing FSDB with fsdbdebug. This time it went through the FSDB reader API (FsdbReader/ffr*), during a 3-minute VCS run dumping +all. The reader polled every ~20 s, both reopening the file in a fresh process and keeping one persistent handle.

Results: - 8 of 8 opens of the growing file succeeded with no errors. - Stored signals (a clock, a timestamp bus, an address bus) and computed/secondary signals (a port alias of the clock, a combinational valid) loaded every time. Secondaries are rebuilt by the reader mid-run too. - A persistent handle sees growth after ffrSync() plus a reload (rc 0, 2-450 ms). Use the reader's 'is complete' flag to know when the dump is closed (it changes from 0 to 1). - Lag: the visible max time matched the sim's progress within ~1 s. - Load times on the growing file matched those on a closed file. - Exactness: 50 of 50 mid-run reads were bit-identical prefixes of the same signal in the finished file (hash of the first n changes). - Polling cost the simulation +0.2% wall time.

Caveat: fsdbdebug's 'primary' list differs mid-run (~79K entries vs 17.5K after close), but the reader API tree and data were consistent. Don't use that tool's classification until the file is closed.

So a converter, indexer or live viewer can run alongside the simulation. Treat each signal's last block as provisional, and mark the file as growing until it's complete.