73bcfddb3d
Clarify prompts share the same emitted-while-detached failure class the pending-approval replay fixed: `clarify.request` rides `_block()`'s pending registry, so a client whose transport was down when the event fired never sees the question and the agent thread stays parked until timeout. Widen the resume snapshot the same way: - tui_gateway/server.py: `_live_session_payload` now carries `pending_clarify` — a read-only snapshot of the clarify prompt still blocking the session, scoped to the owning runtime sid. The registry stays authoritative; the embedded request_id resolves via clarify.respond. - Desktop resume paths (`use-session-actions`) restore the parked clarify into the clarify store (multi_select preserved) and flag needsInput, mirroring restorePendingApproval on both the activate and resume paths. - pending_approval replay now also forwards the queue-injected request_id so the restored prompt responds with exact-request correlation. - Tests: server-side replay + scoping test; harmonized the #82087 replay test with the request_id `_ApprovalEntry` now injects.