fix(desktop): keep the clarify card until it is answered, skipped, or expired

[SlowGreek]

Clicking into a chat that had an unanswered clarify flashed the question card and then lost it — the question became unrecoverable and the agent stayed blocked until agent.clarify_timeout (3600s).

Three independent defects, all fixed here.

1. The card's lifetime was gated on the wrong thing

ClarifyToolLive gated the interactive panel on messageRunning (thread.isRunning && message.status === 'running'). thread.isRunning is fed from busy, and resumeSession sets busyRef true on entry then back to the resumed running in its finally — which the deferred resume path reports as false. So the panel mounted from the persisted tool-call args, then unmounted a beat later.

It now lives and dies with its own request, correlated by request id (a row hydrated from clarify.request) or question text (a tool.start row, whose id is the model's tool_call_id and never matches).

Correlating per row rather than per session is load-bearing: a transcript can hold several clarify rows, and a session-wide match let an older un-resulted row claim a newer request, then strand itself on a spinner when the pending panel rejected the mismatch. That regression was caught in review and is covered by a test verified to fail against the un-correlated version.

2. clarify.request is one-shot and was never replayable

The gateway tracked the wait in _pending / _pending_prompt_payloads but never handed it back, so a reopened window, an app restart, or a reconnect that dropped the frame could never re-arm — the card rendered the stored question with no request_id to answer with.

_session_pending_prompts() now replays still-blocked prompts through _live_session_payload as pending_prompts, and the renderer re-arms on both session.activate and session.resume. Only a live session can hold a blocked prompt, so that is the payload that can carry one.

3. clarify.expire had no desktop handler at all

The gateway emitted it; nothing listened. It now drops the request and the sidebar's needs-input flag — but only when the clear actually happened, so a stale expire cannot silence a session still blocked on a newer question (clearClarifyRequest() returns that verdict).

Also clears parked requests on a gateway switch: they key off runtime session ids the next backend re-mints, and the card no longer self-limits via the running flag.

Verification

• desktop vitest: 2918 passed, 0 failed
• scripts/run_tests.sh tests/tui_gateway/: 487 passed, 0 failed
• npm run typecheck and eslint clean
• The Python test drives the real _block bridge on a worker thread and asserts the replayed request_id actually releases the blocked tool — not a mock.

Reviewed adversarially by a second model, which cleared lock discipline on _prompt_lock (no deadlock), payload safety (sudo -S -p '' payload is {}; secret carries the request, never the value), and backward compat in both directions.

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 89d9d0d}

all good!