VaporView FSDB addon: N-API object per change is 10x the reader cost

Profiling VaporView's FSDB node addon (fsdb_reader.cpp over Verdi's FsdbReader) on a real 164 MB pipeline dump: walking a signal with ffrGotoNextVC/ffrGetVC costs ~96 ns/change (1-bit) to ~205 ns/change (32-bit), but getValueChanges builds a JS [time, string] array per change via Napi::Array::New + Set + String::New + result.Length(), costing ~1,100-1,900 ns/change (2.1 s for a 1.84M-change clock). Packing records ([u64 LE delta][value chars]) into a std::vector in C++ and returning one Napi::Buffer::Copy takes ~214 ms for the same clock; zlib level 1 shrinks it from 16.5 MB to 80 KB. After that, the client becomes the bottleneck: decoding into JS [t,str] arrays plus postMessage structured clone into an iframe costs ~1.7-2.2 s and ~380 MB of WebKit memory per ~1M-change signal, so whole-signal loading doesn't scale past a few signals and you need windowed/level-of-detail loading (a 1,000 px viewport can show at most ~500-1,000 changes per signal).