Fix timeline virtualization limit on large datasets

[jaybird1291]

Summary

Fixes a renderer-side virtualization issue in the base timeline view that prevented navigation beyond ~645k rows on large datasets.

Root cause

The table virtualization relied on a scroll container sized as totalRows * ROW_HEIGHT, which becomes too large for Chromium/Electron on multi-million-row datasets.

Changes

• bound the physical scroll height
• map physical scroll position to logical row position
• update virtual window calculations and row positioning
• keep scrollToRow and context menu positioning aligned with the new mapping

Validation

Tested with output_timeline_stream.csv (cf. #6):

• no filters
• no search
• chronological sort
• reverse chronological sort

The base view can now navigate beyond the previous ~645k-row ceiling:

Fix.mp4

Fixes #6

[r3nzsec]

Thanks for the detailed PR — the approach is exactly right and the analysis in #6 is spot-on (the ~16.7M-px Chromium LayoutUnit ceiling is the actual root cause). I went down the same path on my end and arrived at essentially the same design: bounded physical rail + linear physical↔logical mapping + per-row top adjustment.

A few notes on the change set:

👍 The visibleStartAi = Math.max(si, rowOffset) correction for the non-grouped path is a separate, real bug that I'd missed — good catch.
👍 Adding viewportH to the scroll-fetch effect deps is correct; without it the fetch trigger goes stale on window resize.
The cap at 16M − 4KB is aggressive — it sits just under Blink's saturation point. A more conservative value (e.g. 12–15M) leaves headroom for sub-pixel rounding and zoom-related layout shifts. The explicit renderBaseTop clamp probably makes 4KB margin safe in practice, but worth considering.
Heads up on a merge conflict: a recent local refactor moved the virtual-grid render into src/components/VirtualGrid.jsx and pulled the layout constants into src/constants/grid.js. The four top: rowTopForIndex(ai) updates will need to land in the component file rather than App.jsx, and MAX_VIRTUAL_SCROLL_HEIGHT belongs alongside ROW_HEIGHT in the constants module. Happy to handle the rebase if that's easier.
Validated locally against the same 2.88M-row dataset — the previous ~645K cap is gone in both sort directions.