virtual-core: desktop Safari drops the prepend anchor write when history lands during the top rubber-band bounce

在桌面版 Safari 中使用 pnpm --filter tanstack-react-virtual-example-chat dev 复现，并在顶部橡皮筋回弹期间执行快速 prepend。阅读 setOptions、_willUpdate 和 _flushIosDeferredIfReady，将桌面写入路径与 iOS overscroll 处理以及 #1189 和 #1280 中引用的技术进行比较。完成标准是：以末尾为锚点的列表在回弹期间保持读者所在的行，同时不会渲染空白 viewport。

Describe the bug

On macOS Safari (18.4, navigator.maxTouchPoints 0, so none of the iOS deferral is involved), an end-anchored list loses its reading position when a prepend lands while the scroller is rubber-banding past its top edge.

Sequence, from a per-frame trace of the react chat example (anchorTo: 'end', directDomUpdates: true, 180 ms mock history load):

 1283ms st=159  off=159  range=1-10 count=45 top=1
 1300ms st=0    off=0    range=0-9  count=45 top=0   <- auto history load triggers
 1316ms st=-20  off=-20  range=0-8  count=45 top=0   <- Safari rubber band, scrollTop negative
 1383ms st=-69  off=-69  range=0-8  count=45 top=0
 1466ms st=-51  off=-51  range=0-8  count=45 top=0
 1484ms st=-46  off=-46  range=0-10 count=57 top=-12 <- 12 rows prepended, anchor write lost

setOptions resolves the anchor and _willUpdate writes scrollTop = 842 to keep row 0 in place. WebKit discards a scrollTop write made during an elastic bounce and animates back to 0. The next bounce scroll event reports the DOM value, the tracked offset follows it, and the viewport now shows the newly prepended rows: the reader is exactly one prepend away from where they were. While the eagerly bumped offset and the DOM disagree the viewport can also render blank, since the range is computed for a position the DOM never reaches.

The iOS flush path already treats the overscroll zone as unwritable (_flushIosDeferredIfReady, "Phase 2b"). The desktop write path has no such guard.

Steps to reproduce

1. pnpm --filter tanstack-react-virtual-example-chat dev, open in desktop Safari with a trackpad.
2. Fling upward hard enough to hit the top and bounce.
3. The 180 ms mock load lands during the bounce. The list shows the newly loaded rows instead of the row you were reading.

With a slower (real) backend the load usually lands after the bounce has settled and the write goes through, so this needs a fast prepend to trigger. Cached or prefetched history makes that common.

What was tried

A deferral of writes made while scrollOffset < 0, replayed on the first in-bounds scroll event, lands on the correct row but shows the new rows for the duration of the bounce and then snaps back. That reads as a glitch every time and was dropped from #1280. On WebKit the reader's row cannot be held still through the bounce with scrollTop at all.

Options

• App level, to verify first: overscroll-behavior: none on the scroll container. Safari 16+ supports it and per spec none suppresses the boundary bounce. If it removes the rubber band, the failure window disappears and the chat docs can recommend it next to overflow-anchor: none.
• Core: a CSS offset on the container for the bounce window, swapped for a real scrollTop write once the offset is back in bounds. This is the technique from #1189, scoped to this one case.
• Example: the auto-load fires on every bounce scroll event below 120 px, so after the first load finishes the bounce triggers a second one. Independent of the core issue, but it amplifies it.

Platform

• macOS, Safari 18.4 (20621.1.15.11.10)
• @tanstack/virtual-core at main (also reproduces with #1280 applied; unrelated to the iOS path)

Related: #1280, #1189, #884.