perf(grid): offload GridFilterEngine to background isolate and debounce in ResultsTab #1347

Summary

In lib/features/workspace/results_tab.dart (lines 112–140, 334), _getFilteredRows(widget.rows) calls GridFilterEngine.filterRowIndices(...) synchronously on the Flutter UI thread inside ResultsTab.build().

For medium-to-large result sets (10,000–50,000 rows across 20–50 columns), filterRowIndices:

• Iterates over all rows.
• Evaluates tokenization / predicates / substring searches with .toLowerCase() on every column of every row.
• Performs hundreds of thousands of string allocations and comparisons synchronously on the main thread during typing.

While grid_sorting.dart already offloads sorting to an isolate above 3,000 rows (kSortIsolateThreshold = 3000 via foundation.compute), and grid_selection_calc_engine.dart offloads metrics above 5,000 values (kCalcIsolateThreshold = 5000), filtering runs synchronously on every keystroke with zero background processing.
Furthermore, Epic B (#568, #569) introduces a full recursive-descent AST parser with AND, OR, LIKE, IN, which will make per-row evaluation significantly more CPU intensive.

Proposed Solution

1. Add isolate offloading for GridFilterEngine.filterRowIndices using compute when row count exceeds a threshold (e.g. kFilterIsolateThreshold = 3000).
2. Add a debounced asynchronous filter execution model in ResultsTab (e.g. 100–150 ms debounce while typing in DataGridFilterBar).
3. Cancel obsolete in-flight isolate jobs when the user enters new search characters.

Acceptance Criteria

• GridFilterEngine.filterRowIndices does not block the UI thread on result sets > 3,000 rows.
• Typing in DataGridFilterBar maintains smooth 60/120 Hz frame budget without frame drops.
• Filtering remains deterministic and cancels outdated in-flight isolate tasks when query changes.