bug(workspace): "lost track of this turn" is a dead end — the reply lands but the UI never recovers (no poll, no badge, no push)

[trinity-ability]

Context

The #2120 → #2133 → #2214 chain (shipped in v0.9.0) made the Workspace wait for a reply on the server's own budget: the 202 carries wait_budget_seconds = 2 × (execution_timeout_seconds + 10 + 300) + 60 (≈2h11m for the 3600s default), the in-flight marker gets the same TTL, and reattach rides the marker's remaining TTL. That fixed the pre-v0.9.0 behavior where every Workspace turn longer than ~21 minutes ended in:

Still no reply — we've lost track of this turn. It may still finish; check the conversation shortly.

The residual

When the client does reach the lost state, it is a terminal dead end:

• awaitPersistedReply returns {lost: true} and all watching stops (PortalConversation.vue:754-760). No slow background poll, nothing.
• The message tells the user to "check the conversation shortly", but the UI never does that itself: when the reply later persists, the open thread never renders it, and the sidebar unread badge never appears — sessions-changed is only emitted from the very closure that just gave up, and per bug: Agent Detail and Workspace over-fetch on load (21 redundant requests, N+1 roster) #2198 the thread list is purely event-driven (no interval, no visibilitychange handler, no portal-facing WS/SSE push). The user has to manually switch threads or reload.
• The wording is the same regardless of what the server says at the deadline. The client's last history read knows whether in_flight_execution_id is still set — "your task is still running, the reply will appear here" and "we genuinely lost it" are different situations rendered with one pessimistic message.
• The lost state is still reachable routinely for a new client against a pre-bug: Workspace chat turns are hard-capped at 300s, ignoring the agent's configured execution timeout #2214 backend: resolveWaitBudgetMs deliberately under-waits at the frozen 1280s fallback (documented in portalUtils.js — correct, but it makes graceful post-lost handling matter more, since mixed-version fleets will show this exact message on every >21min turn).

Suggested handling

Any subset; the constraint that must survive is never offer Retry for a turn that may have run (#2120's double-billing hazard):

1. Post-lost slow poll: after lost, keep polling history at a wide interval (30–60s) bounded by the marker: while the server still reports the turn in-flight, render a "still working — taking longer than expected" state instead of the terminal message; when the marker clears, one final read either renders the reply or reports the honest no-answer.
2. Word by marker state at the deadline: marker alive → "still running"; marker gone + no reply → today's message.
3. Badge recovery: refreshThreads on visibilitychange/thread re-open so the unread badge surfaces a reply that landed after the client stopped watching.

Acceptance criteria

• A reply that persists after the client's wait budget expires becomes visible without a manual reload (open thread updates, or at minimum the sidebar badges it)
• The lost-state message distinguishes "server still reports the turn in-flight" from "marker gone"
• No path re-introduces a Retry for a possibly-billed turn (existing test_2133_*/bug: Workspace chat turns are hard-capped at 300s, ignoring the agent's configured execution timeout #2214 pins keep holding)
• Post-lost polling is bounded and slow (no return of the ~850-requests-per-tab tail bug(workspace): awaitPersistedReply can poll for an hour when the in-flight marker is orphaned #2133 removed)

Ops note (not part of this issue)

The common cause of the message today is version skew, not this residual: instances must run v0.9.0 on both backend and frontend to get the per-agent budget, and agents that legitimately run long need execution_timeout_seconds raised (PUT /api/agents/{name}/timeout, 60–7200) — the Workspace budget follows it.

Related: #2120, #2133, #2214, #2198, abilityai/trinity-enterprise#286, abilityai/trinity-enterprise#358

[trinity-ability]

Sibling filed: #2320 — the fast twin. This issue covers recovery after the client legitimately loses a long turn; #2320 covers fast-failing turns being structurally invisible (no persisted failure record, marker cleared → the 6s idle give-up renders the same "lost track" message for a turn the server knows failed, discarding the backend's composed error and suppressing Retry on the one path where it's safe). Live-instance evidence over there. If #2320 lands the typed last-turn-outcome record, the post-lost slow poll here should read it too.

[vybe]

Into the v0.9.5 cut as upside — operator decision 2026-09-06 (decision 10): the fast twin (#2320) is merged; this dead end is what a long turn still hits. Assigned to @obasilakis, who built #2320 — the typed last-turn-outcome record it added is the natural base for the post-lost poll. Not a floor bar.