test(zero-swift): wait for the deleted jump row's successor, not 2 s (#192)

theRowAJumpLandedOnIsDeleted gave the delete a fixed 2 s of wall-clock
time to reach the list. That takes several turns of the main actor, which
the other @mainactor suites share; HardenStorageTests' busy-write tests
hold it for seconds at a time (SQLite's 5 s busy timeout). When such a
stall covered the window, the test woke after it and read the list before
the delete had arrived: "on screen: n150".

It now waits for n151 to come up, then checks it stays, as it waits for the
jump before the delete.

Amp-Thread-ID: https://ampcode.com/threads/T-01a1d36c-588f-74c1-ab26-4bb389433e40

Co-authored-by: Amp <amp@ampcode.com>

Author: tmm

swift/Tests/AppleTests/VirtualListViewTests.swift

@@ -217,7 +217,12 @@
       try await t.run(0.5) { false }
       #expect(list.firstVisibleItem()?.key == VirtualListTests.id(150))
       server.delete("note", ["id": .string(VirtualListTests.id(150))])
-      try await t.run(2) { false }
+      // The delete reaches the list over several turns of the main actor,
+      // which the other suites' tests share and can hold for seconds (a
+      // SQLite busy wait): a fixed wait can run out before them. Waited for,
+      // as the jump is above.
+      try await t.run(30) { list.firstVisibleItem()?.key == VirtualListTests.id(151) }
+      try await t.run(0.5) { false }
       // n151 comes up into its place.
       #expect(
         list.firstVisibleItem()?.key == VirtualListTests.id(151),