statusline: members remain stuck in busy state indefinitely

[kumaakh]

Problem

Fleet members frequently show as busy in the statusline long after their execute_prompt has completed or been cancelled. The busy state is never cleared, so the member appears occupied indefinitely until the server is restarted.

Impact

• fleet_status shows wrong state — PM cannot reliably tell if a member is safe to dispatch to
• The concurrent dispatch guard fires incorrectly, blocking legitimate dispatches with "execute_prompt is already running"
• Workaround is manual stop_prompt or server restart

Expected behaviour

Busy state clears as soon as execute_prompt exits — whether by normal completion, timeout, cancellation, or crash.

Likely causes to investigate

• PID capture races: if FLEET_PID: is never emitted (process crash before output, or stdout pipe lost), the session never records a PID and the busy flag may not clear on exit
• AbortSignal / cancellation path: if the MCP client cancels mid-stream, the close/error handlers that clear busy state may not fire
• stop_prompt followed by immediate re-dispatch: the stopped flag may linger and block the next dispatch even after the process is dead
• Crash or unhandled rejection in the execution pipeline leaving the member locked