Follow a card that moved, and wait for the answer a move invalidated

Switching a branch makes the build out of date, which moves the card out
of "Up to date" and somewhere else entirely on a list of ten. The list
now scrolls to it -- only when it is actually off screen, since moving
something the reader can already see is a jump nobody asked for. The two
frames before reading the position are load-bearing: the entry has just
been applied, so the first frame carries the composition and the second
reports the layout it produced, and reading sooner gives where the card
was.

The other half is why a switched branch showed no commits and no Pull.
The build machine drops what it knew about that checkout's remote and
asks again, but the answer lands after the response -- and startCheckout
read the entry exactly once, so the card kept a pending check for ever.
It waits on awaitCheck now, the same poll the card's own Refresh uses.

Reproduced against a clone of ai-app before changing anything:
immediately after the move newCommits false with checkPending true,
three seconds later newCommits true, and nothing asking again in
between.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AGENTS.md

@@ -599,6 +599,29 @@ mutable at runtime from the phone.
   small note in one component's row to say otherwise. Iris found it by
   switching ai-app onto another branch and seeing nothing flagged.
 
+- **The list follows a card that an action moved, and a checkout waits
+  for the answer before it stops.** Two halves of the same press, both
+  Iris's, 2026-09-02. Switching a branch makes the build out of date,
+  which moves the card out of "Up to date" and somewhere else entirely
+  on a list of ten: `followCard` scrolls to it, but only when it is
+  actually off screen, since moving something the reader can already see
+  is a jump they did not ask for. It waits two frames first -- the entry
+  has just been applied, so the first frame carries the composition and
+  the second reports the layout it produced; reading the position before
+  both have passed gives where the card *was*. Positions come from an
+  `onGloballyPositioned` per card (`CardPlace`) rather than from the
+  order, because the cards are different heights and the headings count
+  too.
+  And `startCheckout` now waits on `awaitCheck` afterwards. The build
+  machine drops what it knew about that checkout's remote and asks again,
+  but the answer lands *after* the response -- so with a single read the
+  card kept a pending check for ever: no commit count, Pull disabled, on
+  a branch with commits waiting. That was the whole of "it doesn't show
+  any updates or the ability to pull even tho there's obviously new
+  stuff", reproduced against a clone of ai-app: immediately after the
+  move `newCommits: false, checkPending: true`, three seconds later
+  `newCommits: true` -- with nothing asking again in between.
+
 - **A moved checkout re-asks its remote, because the last answer was
   about the branch it left.** `RemoteChecks::recheck` forgets the cached
   answer and starts a fresh check, called from `move_checkout` where the