Upstream VaporView FSDB: whole-signal load on add, no backend decimation, no cross-session cache

Read of github.com/Lramseyer/vaporview main (1.6.1, Nov 2026). FSDB goes through an optional Node-API addon (src/fsdb_reader.cpp, node-gyp, paths hand-edited in binding.gyp; package.json has gypfile:false so npm install does not build it, and the marketplace prepublish script does not compile it). It runs in a child_process.fork of dist/fsdb_worker.js from the extension host (extensionKind workspace, so on the remote under Remote-SSH), Linux only. Open reads the scope tree only (lazy since 1.6.1, commit 2e3e36b); vars per scope on expand. On signal add, getSignalData calls ffrLoadSignals then walks every change into a JS [time,string] array and posts it to the webview as one chunk: no t0/t1 anywhere in the FSDB worker command set. Zoom-to-fit is viewport-only; the canvas renderer loops over every change in view and skips sub-pixel draws, so full-zoom-out cost scales with total change count. unloadSignal exists in the addon but the handler never calls it. getValuesAtTime reads time with Uint32Value (times above 2^32 truncated). The wellen wasm path (VCD/FST/GHW) has the same model: load_signals then serialize the whole history (JSON or LZ4 delta records, 65000-byte chunks). The only FSDB changelog line is 1.6.1 "Improve performance with large FSDB design files", which is the lazy netlist, not value loading.