[Bug] claude_code: AskUserQuestion/plan dialogs classify as idle/completed — inbox delivery auto-answers user decision dialogs

## Symptom

When a `claude_code` terminal is showing an interactive decision dialog (AskUserQuestion option picker, plan-approval prompt), the provider's status detection classifies the screen as `idle` or `completed` — not `waiting_user_answer`.

Because inbox delivery gates only on idle/completed, a queued message is then delivered into the dialog: the message text is typed and the trailing **Enter submits the currently-focused dialog option** (for AskUserQuestion that's the first/"Recommended" one). A worker's callback can literally answer a human's decision dialog.

## Observed live

2026-07-09 ~17:59 (local logs): a supervisor terminal's AskUserQuestion dialog was auto-answered by an incoming worker-callback delivery — the Enter keystroke selected the recommended option without any human input.

## Root cause pointer

- `src/cli_agent_orchestrator/providers/claude_code.py` — status detection has no `WAITING_USER_ANSWER` classification for AskUserQuestion / plan-approval screens; the surrounding idle chrome wins.
- `src/cli_agent_orchestrator/services/inbox_service.py` — delivery treats idle/completed as safe-to-type.

Any dialog-protection layer that defers delivery on `waiting_user_answer` is inert for these screens because the classification never happens.

## Suggested direction

Classify Claude Code's decision dialogs (option list + keyboard-focus chrome) as `WAITING_USER_ANSWER` so delivery holds until the human answers. A conservative screen-pattern match on the AskUserQuestion frame is enough; false-WAITING is far safer than auto-answering a user decision.

Found while operating a long-running multi-agent fork of this repo; happy to provide captured frames.