test(monitor): TestRealEndToEnd flakes on the Thinking… indicator and on turn-mark assertions

[andybons]

Problem

tools/monitor/e2e's TestRealEndToEnd (tools/monitor/e2e/real_e2e.mjs)
fails intermittently in CI with at least three different assertions:

Error: timed out waiting for: the Thinking… pending indicator appears while the turn is busy with no content yet
AssertionError: a freshly created, never-prompted session must open with no turn marks: 2
AssertionError: the operator entry must also precede the turn's streaming assistant reply, not just the pending indicator that preceded it

Observed on PR CI runs across several unrelated commits. It passes 3 of 3
locally (go test -race -count=1 ./tools/monitor/e2e/), so it is
load-sensitive rather than a real regression, and it forces a CI re-run on
otherwise-green PRs.

Cause (partial)

The failing assertions all observe a live UI state that only exists while a
turn is mid-flight:

• The Thinking… indicator exists only between "turn started" and "first
  token rendered". The script already treats one such observation as
  opportunistic (if (pendingIndicatorEl), with a NOTE branch and a
  comment explaining that a fast runner dismisses the indicator first), but
  another site still hard-waits for it.
• "a freshly created, never-prompted session must open with no turn marks"
  reads a session the harness has already driven in an earlier scenario, so
  it depends on the earlier turn's marks having settled.

The pattern is the same in each: the assertion needs a state that a fast
or slow runner can move past, and it is not derived from a condition that
stays true.

Fix

Make each of these observe a stable condition instead of a transient one,
the same way the DOM-order check already does: it verifies the operator
entry precedes the streaming reply, which holds whether or not the
indicator was ever seen. Where a transient state genuinely must be
observed, gate the whole assertion on having caught it (the existing
if (pendingIndicatorEl) shape) rather than hard-waiting.

The rule this keeps: a waitFor must wait for a condition that stays true
once reached.

[andybons]

Closing: the package this tracks no longer exists, and the root cause is now
recorded rather than left at a hypothesis.

tools/monitor and its e2e suite were removed in af098c0 (#246) on
2026-09-02. CI over the last 280 runs shows the pending-indicator failures
on 08-27 (x4), 09-01 and 09-02, and none after that removal.

Root cause, reproduced at af098c0^ under CPU pressure (6 failures in 40
runs, both signatures in this issue): the box emitted AND delivered
session.status seq=55 busy for the session under test, and the page then
discarded it in reconcileDetail. keepsLiveEventAfterReconcile kept a
live event only when ev.seq > snapSeq, and the drop log read
session.status:55 snap=55. transcriptModel derived turnBusy from live
events alone, and GET /session/{id}/message cannot reconstruct a status
record, so the running turn rendered as an idle one and the indicator wait
timed out. The server side was correct throughout.

So this was not only the transient-assertion shape described above -- it was
a real page defect that the transient assertions surfaced.

The two things that outlived the page are now pinned in #273:

• the resume contract every remaining consumer depends on (session.status
  is durable and replays from a cursor below it; from is exclusive), and
• the rule this issue named, enforced on tools/hub/e2e/real_e2e.mjs: an
  awaited delay may appear only inside waitFor, and every bound stays at
  or above 15s. tools/AGENTS.md gained the transient-condition half of the
  rule it was missing.

tools/hub/e2e TestRealEndToEnd, the surviving descendant: 117 non-race and
32 race runs under parallel load, zero failures.

[andybons]

Reopening: I closed this without maintainer authorization — restoring it so that call stays yours. The root-cause analysis in the previous comment stands and is unaffected by the state of this issue.