perf(grid): isolate selection updates and decouple selection stats from grid rebuild #885

Summary

VirtualResultGrid and ResultsTab trigger multiple whole-tree rebuilds during cell selection changes and keyboard/mouse navigation.

1. Rebuild cascade: On every selection step (_jumpToCell, _selectAll, secondary tap, etc.), VirtualResultGrid.setState is called, followed immediately by _notifySelectionAndFocus().
2. Synchronous string allocations: _notifySelectionAndFocus() iterates through the selection bounding box and allocates List<String> values containing all selected cell strings.
3. Double setState on parent: ResultsTab hooks onSelectionValuesChanged and onCellFocused. In both callbacks, it immediately calls setState(). This forces ResultsTab (including the toolbar, segmented view buttons, status line, and child VirtualResultGrid) to rebuild twice for every navigation event.
4. Synchronous math on UI thread: GridSelectionCalcEngine.compute(values) runs synchronously for selections under threshold, parsing strings to doubles and calculating sum, avg, min, max, count on the main thread during navigation.

This easily breaches the 8.3ms frame budget @ 120 Hz when navigating or dragging selections in large grids.

Scope

• Decouple selection statistics display in the status bar using a ValueNotifier<GridCalcStats> or targeted sub-widget so updating stats does not rebuild the entire ResultsTab or VirtualResultGrid.
• Isolate _focusedColumnName, _focusedCellValue, and _focusedRowIndex updates from the rest of the ResultsTab chrome.
• Throttle or debounce calculation of selection aggregates during rapid navigation / drag.
• Ensure onSelectionValuesChanged does not trigger synchronous double rebuilds of the grid.

Out of scope

• Virtualization of columns or row cells.
• Asynchronous compute worker pools for large aggregations (handled by computeAdaptive).