perf(editor): virtualize line rendering and throttle layout passes for large SQL scripts (>2000 lines) #1506

Summary

In lib/core/editor/querya_code_editor.dart, both material.TextField and shadcn.TextField rely on Flutter's RenderEditable, which constructs a single contiguous Paragraph layout for the entire document buffer.

While QueryaHighlightController (#1351) successfully isolates syntax regex tokenization into an isolate for scripts $\ge 8$ KB, the Flutter engine itself must still measure, lay out, and shape glyphs for the entire document synchronously on the UI thread:

1. When loading large SQL migration files, schema dumps, or multi-statement scripts (> 2,000 lines / > 500 KB), every single keystroke, character deletion, or selection update forces a synchronous layout pass over the entire multi-thousand line buffer.
2. Frame render times spike to 40–120 ms (causing visible hitching and violating the 120 Hz budget of epic epic(perf): steady 120 Hz without drops (profile findings, Sep 2026) #987).
3. Fast scrolling through large scripts causes GC pressure and continuous layout thrashing.

Proposed Solution

1. Viewport Windowing / Chunking:
   • Introduce virtualized line / block rendering for read-only and large editable buffers exceeding a threshold (e.g. > 2000 lines or > 500 KB), rendering only lines visible in the current viewport plus a buffer margin.
2. Throttled / Debounced Layout:
   • Avoid eager layout recalculation across unviewed blocks on every cursor blink or minor selection modification.
3. Chunked Text Editing Bridge:
   • For ultra-large SQL files (> 10,000 lines), consider dividing the document into line blocks or integrating a specialized virtualized code-editor renderer.

Acceptance Criteria

• Typing and scrolling in SQL scripts with 5,000+ lines maintains smooth 60/120 Hz frame budget.
• UI thread frame build times stay under 8.3 ms during fast keyboard navigation in large scripts.
• No regression in cursor positioning, text selection, or isolate syntax highlighting.