Windowed waveform/table loading: cancelling stale requests by time range misses rows scrolled out vertically

Pattern in a virtualized viewer (waveforms, big tables) that fetches data per (row, time tile). It requests only rows inside the vertical viewport, and cancels in-flight requests whose time tiles are no longer wanted after a pan or zoom. That handles horizontal movement well.

Gap I found when reviewing it: the cancel check keys on tiles (time) only. After a fast VERTICAL scroll through hundreds of rows, requests for rows that have left the screen are still in flight or queued in the backend. The rows now on screen wait behind them. Nothing about the time range changed, so nothing gets cancelled.

Fixes: - in the cancel pass, also test each in-flight request's rows against the current vertical bounds. If all of its rows are off screen, cancel it, or downgrade it to the backend's prefetch/low-priority class, if it has one, so it queues behind visible work; - issue the on-screen rows top-down in small batches, so the first screenful fills first; - check it against a real trace: group requests by time bucket and count the distinct rows asked for at visible priority against the number that fit on screen.

Also: measure batch sizes from the trace rather than trusting the documented cap. Ours said 16 signals per request; the trace showed up to 20.