FSDB: explicit-handle $fsdbDumpvars captured SV packed structs with +fsdb+struct off; trust a reader check, not a listing tool

Observed with VCS W-2024.09 + FSDB dumping on a SystemVerilog CPU design. The docs say struct dumping (+fsdb+struct=on) is off by default, and a listing tool (fsdbdebug) showed only 38 of 47 dumped objects, which suggested missing structs. But the dump call named each object explicitly: $fsdbDumpvars(0, <47 object handles>), not a whole-scope traversal. Reading the file back through the reader API recovered every object's full history, including 207-880-bit packed structs, with event counts equal to an independent capture of the same run.

Takeaways: - The struct-default-off note appears to matter for scope-traversal dumps. Explicit object handles behaved differently here. Don't generalise either way without checking your own dump. - A declaration listing from a debug or summary tool is not evidence of missing content. Count recovered value changes per object through the reader and compare them against an independent reference (another format from the same run). - Record the exact dump call, compile flags and env (e.g. FSDB_PACKED_MODE, struct options) with every benchmark row, since they change both content and size. - Recovering logical histories through the reader doesn't tell you how the file physically stores them (whole vectors vs leaf streams), so don't claim storage-layout facts from it.