[BUG] Background sessions waiting on AskUserQuestion show as 'working', not 'needs input'

Description

Background sessions (claude --bg) that are blocked on an AskUserQuestion tool call do not get flagged as "needs input" — they continue to show status: "busy" / state: "working" in claude agents --json, indistinguishable from a session that's actively working.

This is inconsistent with permission-prompt blocks, which ARE correctly detected and surfaced:

13a407d3 | ... | waiting | blocked | permission prompt
ebc405d7 | ... | waiting | blocked | permission prompt

vs. a session actually waiting on an AskUserQuestion response, which shows:

<id> | ... | busy | working |

Impact

When running multiple background sessions (e.g. via a fleet of claude --bg dispatches), sessions genuinely blocked on a discrete-option question are indistinguishable from sessions still actively executing. This means:

• The Desktop/mobile "needs input" grouping doesn't surface these sessions
• A user has to manually check each "working" session's logs to discover it's actually stalled waiting for a decision

Expected behavior

A session blocked on AskUserQuestion (or any tool that blocks on user response, not just permission prompts) should be classified the same way permission-prompt blocks are — status: "waiting", state: "blocked", with a waitingFor reason (e.g. "AskUserQuestion" or "user input") — so it surfaces under "needs input" in both claude agents and any UI that groups by that status.

Environment

• claude --version: (background daemon / job status classification, CLI-level)
• Reproduced via claude agents --json while running several claude --bg dispatches, some of which called AskUserQuestion and were awaiting a reply.