flaky(e2e): prompt-rail:370 re-reads the rail after the poll that settled it #4675

What happened

The Desktop E2E test manual transcript scrolling keeps exactly the visible prompt current (apps/desktop/e2e/prompt-rail.spec.ts:370) fails intermittently on CI, at the first expectPromptRailMatchesReadingPosition(page) call, before the scroll it is about has happened.

The helper (prompt-rail.spec.ts:191-207) polls until one current tick maps from the Turn being read, then takes a fresh snapshot and asserts it again without polling:

await expect.poll(async () => {
  lastSnapshot = await activePromptRailSnapshot(page);
  return lastSnapshot.expectedId !== null
    && lastSnapshot.currentIds.length === 1
    && lastSnapshot.currentIds[0] === lastSnapshot.expectedId;
}).toBe(true);
const snapshot = await activePromptRailSnapshot(page);
expect(snapshot.expectedId).not.toBeNull();
expect(snapshot.currentIds).toEqual([snapshot.expectedId]);   // <- fails here

Observed on CI:

Error: expect(received).toEqual(expected) // deep equality
  Array [
-   "turn-prompt-rail-119",
+   "turn-prompt-rail-120",
  ]
  at apps/desktop/e2e/prompt-rail.spec.ts:206

The poll passes on a frame where the rail and the reading position agree, and the second snapshot, taken a round trip later, sees the rail one tick further along because the transcript is still settling after scrollTranscriptTo(page, 'bottom'). The second read cannot fail on a settled page, so it only adds a way to fail on an unsettled one. Either the poll's own snapshot should be the one asserted, or the poll should require two consecutive identical snapshots.

How to reproduce

Intermittent; only seen under CI load (Desktop E2E, 4 workers on Xvfb).

1. Push any branch and let the Desktop e2e job run.
2. Seen on main at 486e9ba (run 33782799008) and afe06f2 (run 33735706980), and on PR feat(website): publish the podling site from website/ #4660 at a917af4 (run 33784567871, attempt 1); the diff above is from the PR run.

The test and the helper were both added in #4417 (merged 2026-09-03 08:44 UTC, closing #4415). The first failure is the main run started eight minutes later (afe06f2, 08:52), so this has flaked since it landed: it is in 2 of the 9 red main CI runs among the last 60, plus one PR run, all within nine hours of merging. #4415 is closed and nothing tracks the test itself. #3863 and #4577 settled other timing in this spec; this read is not covered by either.

Environment

• Maka commit: main at 486e9ba, also PR feat(website): publish the podling site from website/ #4660 at a917af4
• OS and version: CI runner, Linux + Xvfb
• Surface: Desktop