fix(transcript): settle tools stranded pending after a lost session.tool.called - #1169

Thanks @pascalandr — all four points addressed in 6d86502, now stacked on #1156 (d969175b) so the reconciliation reuses its coalesced, non-dropping trailing read instead of a second path. The diff collapses onto dev once #1156 lands.

1. P1 (dropped round): the reconciliation no longer touches scheduleAuthoritativeResync(). It now runs one message.invalidate + message.sync on the live reducer after the quiet gate: events keep admitting while the page is in flight, streamed rows survive through the read's row merge (snapshotRows/mergePageWithSnapshot from fix(ui): complete message.list reads under sustained session streaming #1156), and destructive events merely restart the bounded read. Your repro (held response, then a new execution + assistant start + deltas) keeps reducing throughout — no dropping state is ever entered.
2. P2 (window shrink): the entry swap and its onResynced force projection are gone. When the page lands, the re-projection is a plain projectOpenCodeMessages(..., preserveOmitted=true) on the live entry, so the display window keeps its membership and cursor; only the fetched page's rows update.
3. P3 (test): the "outlives" fixture now returns a tool still streaming and asserts one authoritative read across several reconciliation intervals. Verified red-green: removing the serial check makes it read three times and fail; the duplicate check in retireDrainedTranscript was redundant with the guard's own check, so the bound now lives in exactly one place and the test exercises it.
4. P3 (doc): TRANSCRIPT.md and the detector comment now describe the transition precisely — failed still settles a streaming row; the read exists for a streaming row whose round already ended, whose success can never apply.

Validation: 942/942 store tests and tsc --noEmit pass on the stacked head (including #1156's opencode-data-trailing-read/read-merge suites).

Round 2 addressed in 8befef6 — the reconciliation no longer rides the SDK message.sync read at all, which removes the coupling your three points grew out of.

1. Same-row change during the fetch (P2): the fetched page is now authoritative for every row it holds — no live-row override can shadow the stranded tool's terminal state, so the recovery cannot be consumed without healing. Reads are fenced on both sides of the fetch and the seed; a read superseded by admitted events owes one bounded, coalesced retry rather than proceeding.
2. 20-row page leaving older rows behind (P2): the reconcile now reads one full resident window (200 rows) through the root client and seeds it back with unfinished live rows riding along. An older stranded tool inside the window heals, and a running shell the page no longer contains stays in the seeded reducer — its later session.shell.ended still reduces in the row that created it (covered by a test).
3. Trailing-read repair never published (P2): publication now hangs off the reconciliation's own read-and-seed promise, so nothing depends on fix(ui): complete message.list reads under sustained session streaming #1156's trailing read publishing. Once your round-6 fix lands there, this path stays independent of it.

Also: TRANSCRIPT.md now describes the fetched-page-wins semantics and the ride-along rows (the "settles in its reducer" overstatement is gone), and both requested regressions exist — the quiet gate (defers a stranded settlement reconciliation until the stream stays quiet) and display preservation (preserves the display window and unfinished rows through a stranded reconciliation), each verified red with its guard removed, plus the attempt bound (outlives now asserts reads stop once the bound is spent).

Validation: 944/944 store tests and tsc --noEmit pass on 8befef6.

@heunghingwan Thanks for the rebase. Before another review round, I checked where the stranded row comes from on current dev (with #1156 and #1181) by running your first regression against dev's production code:

• As written, it fails on dev, as expected. It never marks the instance connected, so the SDK's own settlement refresh (in @opencode/client's rpc-runtime chunk, around lines 898-900: on an execution terminal event with a streaming or running tool, sync.invalidate then refresh(() => message.sync(...))) is skipped by refresh()'s connected gate.
• With sseManager.seedStatus(instanceId, "connected") added, it still fails on dev: the SDK does run that read, but nothing re-projects the transcript when it completes, so the display keeps "pending" until some later event.

So dev already has the reconciliation this PR rebuilds (it's what isUnsettledAtSettlement's "the reducer reconciles those itself" relies on), with two gaps: it is skipped while not connected, and its result is never published. Since #1156, that read also completes in one fetch while the session keeps streaming, and keeps every live event. That points to a much smaller fix than a separate lane:

• In finishOpenCodeDataEvent, on an execution terminal event whose transcript still holds an unsettled tool, call transcript.entry.data.session.message.sync(sessionId) yourself, without invalidate: the SDK has already invalidated that key, so this shares its in-flight read when it is connected and starts it when it is not. Then, if the transcript is still current, projectOpenCodeMessages(...) and retireDrainedTranscript(...).
• No timers, attempt counters, serials, dedicated 200-row read, mergeReconcileWindow or second publication path. The reducer keeps the SDK's own 20-row page after that read, exactly what its refresh produces on dev today, and the projection keeps the display window.

Your first regression (with and without the connected status), plus one case where a new round streams during the read and keeps its events, would cover it. Would you rework it in that direction? It should land well under 50 lines of production code.

Reworked in d775f02 along exactly that line — the dedicated lane is gone (no timers, attempt counters, serials, 200-row read, mergeReconcileWindow or second publication path; net −254/+69 across the three commits' final shape). finishOpenCodeDataEvent now completes the SDK's own settlement read itself: one message.sync without invalidate on a terminal event whose transcript still holds a streaming or running tool, then — if the transcript is still current — projectOpenCodeMessages(...) and retireDrainedTranscript(...).

One addition your sketch didn't need but runtime-contract's pinned "superseded terminal check" case does: the read is published only when no events were admitted after its settlement (full-data revision unchanged). A read overtaken by a new round stays unpublished, and that round's own settlement reconciles instead — which also answers where the in-flight-round case heals.

The three regressions:

• reconciles a tool stranded pending after settlement — disconnected heal (your first regression, fails on dev);
• reconciles a stranded tool while the stream is connected — with sseManager.seedStatus(instanceId, "connected"), sharing the SDK's own read (also fails on dev, since nothing re-projects it);
• keeps a new round streaming while the settlement read is in flight — the held read lands mid-round: the round keeps its events, the superseded read is not published, streaming continues, and the next settlement heals the tool.

Verified red with the finish-read block disabled (all three fail, reproducing dev), green with it. 939/939 store tests and tsc --noEmit pass on d775f02 (now on dev at d1e3fe6, so the stack has collapsed).

Fixed in 003d746 — the fence is now an execution epoch rather than the full-data revision. Transcripts count admitted session.execution.started events, and the settlement read publishes unless a newer execution superseded its settlement. Same-round activity no longer suppresses the repair:

• your repro is a dedicated test (publishes a settlement read despite a late same-round tool success: held read, late session.tool.success with no new execution, then resolve — display heals). Verified red under the old revision fence, green under the epoch fence;
• the pinned superseded-new-execution check keeps its exact semantics (runtime-contract unchanged and passing);
• the in-flight-round regression now asserts the read lands published with the round's events intact and the tool healed — the narrower fence makes that the expected behavior, not a deferred one.

TRANSCRIPT.md's publication wording follows the corrected fence ("only a newer admitted execution suppresses that publication"). 940/940 store tests and tsc --noEmit pass on 003d746.