[Fix] Pending question panel stays answerable when the reported phase flips

[daniel-lxs]

What problem this solves

Second fix from the steering/questions test pass (repro: task 11nl0xsy05oyl on openmote). The request_user_input panel was rendered only while taskPhase === 'waiting_for_user_input'. A queued or steered follow-up flips the reported phase back to running while the harness turn is still blocked inside the question tool — the question disappeared from the UI with no way to answer it, deadlocking the task ("Working" forever, message queued forever).

What changed

• Panel visibility now tracks the live pendingUserInputRequests list instead of the task phase. The runtime clears pending requests on answer, cancel, and turn teardown, so the list is self-correcting.
• The prompt input's free-text answer routing keys off the active pending request for the same reason — in the desynced state, typed text must answer the visible question rather than being sent as a regular message.
• Dropped the now-unused taskPhase plumbing from both spots.

Complements #32 (web sends steer the active turn): #32 makes the deadlock much harder to reach from the web path; this one makes the question panel correct regardless of how the phase and queue got into that state. The PRs touch different hunks of PromptInput.tsx and merge cleanly in either order.

Validation

• New PendingUserInputRequestPanel.client.test.tsx: pending question renders regardless of reported phase; empty state renders nothing.
• Full src/app/(sandbox)/task/ suite green (478 tests); pnpm lint:fast and pnpm check-types:fast clean.

🤖 Generated with Claude Code

[roomote-roomote-v1]

1 issue outstanding. See task

• apps/web/src/app/(sandbox)/task/[taskId]/PendingUserInputRequestPanel.tsx:158 now renders every request left in the client pending list, but the cancel/session-error paths only clear the worker-side map and emit TaskAborted; the client never removes the matching pendingUserInputRequests. After cancelling a visible question, the stale request remains answerable, and free-text submissions can be swallowed as answers to an unknown request instead of being sent as normal prompts.