[tmm]

VirtualListViewTests.theRowAJumpLandedOnIsDeleted failed on macOS CI at 02c6ab9 on main and on #180 with on screen: n150, and passed on rerun.

Cause

The test, not ZeroVirtual. After deleting n150 it waited a fixed 2 s of wall-clock time, then checked that n151 had come up. The delete reaches the list over several turns of the main actor (poke playback, the page queries, the layout pass). The other @MainActor suites share the main actor, and HardenStorageTests' busy-write tests hold it for seconds at a time (SQLite's 5 s busy timeout). When a stall covered the 2 s window, the test woke after the window and read the list before the delete had reached it.

Evidence:

• A traced CI run (5 repeats of the suite) showed the main actor stalled for 15.3 s, and then 1.2 s, during the test. n151 came up about 60 ms of main-actor time after it was free again.
• In the failing run on main, the failure lands next to aBusyWriteThatStillFailsAtCloseIsReported (15.3 s). Running the two together on a Mac stalls the test's main actor for 10.9 s.
• Holding the main actor for 2.5 s right after the delete fails the old test 5 times out of 5 with CI's exact message (on screen: n150). The fixed test passes with stalls of 2.5 s, 5 s and 15 s.

Fix

The test now waits for n151 to come up, then checks it stays there. This is how the test already waits for the jump before the delete. It is not a longer timeout: it no longer depends on how long the main actor is busy. It still catches a regression: with the deleted-row reanchor broken, it fails with on screen: n070.

Stability (Mac, Xcode 26.6 / Swift 6.3.3, as CI)

• 100 runs of the test on its own: 100 passed.
• 25 runs paired with HardenStorageTests' busy-write tests: 25 passed.
• 6 runs of the full macOS suite (348 tests): all passed.

Test-only change, so no changeset.