[Epic] Resolve Grid Scroll Thrashing via E2E Benchmarking

The Problem: While mousewheel scrolling performs smoothly, grabbing and rapidly dragging the custom vertical scrollbar thumb on a massive grid (e.g., 50k rows in DevIndex) results in prolonged periods of blank content and flickering upon release.

Root Cause Hypothesis: The bottleneck is the triangular worker communication pipeline (App => VDom => Main => App). Even if this pipeline completes rapidly, a high-velocity thumb drag can move the scroll position hundreds of rows ahead during that window. When the VDOM payload arrives, it renders rows for a viewport the user has already left, resulting in a blank screen until the scroll stops and the pipeline catches up.

Context from Previous Session (Epic #9369): We recently implemented a granular, Set-based locking mechanism (coordinatingNodes) in ScrollSync.mjs with a 50ms debounced setTimeout to prevent native event feedback loops. We need to investigate if this lock interacts poorly with the high-velocity syncGridBody throttle or the final VDOM paint.

Strategic Goals for this Epic:

1. Deterministic E2E Reproduction:
   • Create a dedicated Playwright test (e.g., GridThumbDrag.spec.mjs).
   • Programmatically simulate high-velocity thumb dragging using Playwright's mouse APIs.
   • Crucial Assertion: During the drag, extract the translate3d(x, Y, z) values from the currently mounted .neo-grid-row DOM elements and compare them to the actual scrollTop of the .neo-grid-body-wrapper. A large discrepancy mathematically proves the "stale render" gap.
2. Velocity-Aware Architecture:
   • Use the E2E test to validate potential solutions, such as dynamically expanding the bufferRowRange based on active scroll velocity, ensuring the pipeline paints further ahead in the direction of the drag.
3. Locking Audit:
   • Verify if the ScrollSync 50ms lock is artificially delaying the final "resting" VDOM payload paint upon thumb release.