[modacker]

What broke

packages/webui/test/integration/agent-transcript.test.ts asserts that a message queued behind an active turn is delivered afterwards, in order, and that the queue row disappears once it drains. On CI that case fails roughly half the time, and it fails on the unmodified base commit as well — it is not a regression of any open change, it is a product defect that Jiaxiaoyuan's 97e33fd8 ("resolve queue drain race after turn terminal release") did not actually resolve.

The browser ends up with no trace of the drained turn at all: the queued reply is never rendered and the queue row stays on screen. Two independent defects produce that.

1. The runtime decides "replay only" from a racy projection. resumeSession used the session's persisted status to decide whether a resumed stream should be live or replay-only. That status is an asynchronous projection of state events, so while a turn is running it still reads idle — and for a drained turn especially so. The runtime therefore served a replay-only stream and closed it before the queued reply was committed, so that reply never reached the browser. The runtime contradicts itself in the same breath: the client's getActiveTurn answered busyReason: "turn" (a turn is active) while resumeSession answered status="idle".

2. The browser loses every event published before its event channel opens. The event channel is a separate socket from the request channel. In the failing runs the server completed the handshake in 11ms while the browser's open event only fired 3.4s later; every event published in that window — including session.start for the drained turn and three session.queue.updated events — was lost. The page therefore never learned the turn had started, and the queue row it was already showing never got told to go away.

What this changes

• packages/local-runtime-v2/src/application/conversation/conversation-application.ts — the liveness of a resumed stream now comes from the authoritative active turn (turnInspection.activeTurnId, the same answer the client's getActiveTurn gives) instead of the racy persisted status.
• packages/local-runtime-v2/src/service/session-system/stream/session-stream-service.ts — the service remembers which turn published the last terminal event, so a resumed stream that follows an already-finished turn ends at the replay instead of waiting forever for a terminal that will never come. This closes the hang window the first change would otherwise open.
• packages/webui/src/client/application/create-application.ts — when the event channel becomes ready the client converges on the authoritative state: it re-reads the transcript head (a turn that finished inside the window is in no probe result) and re-reads the queue (an item drained inside the window leaves no residual row).

The guarantee only gets stronger: a queued message is delivered in order and the queue is emptied. The failing test file is not touched — git diff 97e33fd8 -- packages/webui/test/ is empty. No skip, no retry, no widened timeout, no weakened expectation.

How it was checked

The defect was reproduced locally on the pristine base commit (the macOS form of the failure: getByText('Queued follow-up delivered.') — element not found), and instrumented in three layers to separate "the runtime never published it" from "the browser never received it":

observation	result
runtime published session.queue.updated x3, session.start (queued drain), session.finish	all present
global events the browser actually received	none of them
event channel socket	server handshake done in 11ms, browser open fired 3.4s later
getActiveTurn vs resumeSession	busyReason: "turn" vs status="idle"

With the fix in place:

• the target case, run repeatedly: 14 consecutive passes (the base fails about half the time);
• test:webui whole group, CI-equivalent (213 files): 213 files, 3264 passed, 34 skipped;
• test:capability (covers local-runtime-v2): 237 files, 5815 passed;
• policy / status-contract / sandbox: green (142 / 9 / 48); typecheck, typecheck:webui, check:source, check:webui-boundary, check:webui-dependency: green;
• deterministic red: the new session-stream-service.test.ts disables the end-of-stream logic on purpose and fails with Error: the resumed stream did not end — a condition failure, not a timeout — and passes again once restored.

Not addressed here

• Why the browser's event channel opens seconds late. The server's handshake completes immediately; the delay is on the browser side (suspected: one websocket per request contending for the per-origin connection budget). This PR does not change the transport. It makes the page converge on the authoritative state once the channel is ready, which is the lowest-risk fix — but treating the cause would mean a transport change (reusing a single connection), which is a larger piece of work.
• The activeTurnId half has no unit test. The new unit test covers the stream-service end-of-stream semantics; the runtime's active-turn lookup is covered only end to end by the integration case.
• The refresh uses the selected session id. channelReady refreshes the transcript for store.getSelectedSessionId(). If the view ever presents a session other than the selected one, that could in principle switch the presentation slot. The two agree on every path exercised here, and no counter-example was constructed.

Publication and contribution checks

• I have permission to contribute these changes under the existing licenses applicable to the changed files/packages; imported material and its provenance are identified and existing notices are preserved.
• No credentials, account data, real user content, internal source history or private review material is included.
• Added/removed source files were reviewed before regenerating release/public-source.json; new tests are declared in test/vitest-suites.json where applicable. — release/public-source.json was regenerated with node scripts/source-inventory.mjs --write and test/vitest-suites.json declares the new test file.
• Shared English/Chinese documentation and capability/verification records are updated where applicable. — No document describes the old behaviour, so none needed updating.

Maintainer handoff

Publication scope or license changes (if any): none.

Shared-source port: not needed.