FleetView agent shows "running" while blocked on AskUserQuestion / permission prompt

Summary

When an agent inside FleetView is blocked on tool-level user input — either an AskUserQuestion prompt or a permission confirmation dialog (Bash, Edit, etc.) — FleetView still shows its status as running, never needs input / waiting. The agent sits there indefinitely with no outward indication that it's blocked; you only find out when you open its tab.

Steps to reproduce

1. Spawn an agent in FleetView that will hit AskUserQuestion, or run a tool whose permission isn't pre-approved (e.g. Bash with a non-allowlisted command).
2. Look at the outer FleetView agent list — status stays at running.
3. Open the agent's tab — there's a pending question / permission dialog that's been silently blocking the agent the whole time.

Suspected cause

The state classifier appears to only read the agent's assistant-message text, looking for sentinels like result:, needs input:, failed:. When the agent is blocked mid-tool-call, no new assistant text is produced after the tool call started — so no sentinel ever appears, and the outer state stays at running.

AskUserQuestion and permission prompts are tool-level interactions that the text-sentinel classifier has no way to observe.

Impact

Makes parallel-agent supervision unreliable: the running indicator doesn't distinguish actively-working agents from silently-stuck ones. The whole point of FleetView is to fan out work and check back later — but if the status can't be trusted, you end up polling each tab manually, which defeats the feature.

Request

FleetView should detect "pending permission prompt" / "unanswered AskUserQuestion" as a first-class waiting state, independent of the text-sentinel classifier, and surface it in the outer agent list (e.g. a dedicated needs input indicator on the agent card).