Status line conflates "actively generating" with "idle + background work running" — users can't tell when it's safe to type

### Describe the bug

Problem: Whenever background work is running — a background subagent (task tool) or a backgrounded shell command — the status line shows "Working / Waiting for background agents" even when the parent agent is fully idle (not generating). Empirically, typing in that state works fine: prompts go pending and run on one Enter. But the status looks busy, so users avoid typing, or mistime it and type during actual generation, which silently puts them into a sticky N-1 queue (each Enter submits the previous prompt and queues the current; only drains if you pause or hit Enter on an empty line).

Root cause (from app.js): the busy indicator is driven by  hasActiveWork = isProcessing || hasActiveBackgroundWork() , where  hasActiveBackgroundWork()  is true for running agents or running attached shell commands. The "Waiting for background agents" text ( currentIntent ) is consumed only by the terminal title and status-line component — it's cosmetic and does not gate input. The actual input gate is  isProcessing  (mid-turn) only. So any parked background process makes the UI say busy while input is functionally free.

Impact: Users can't distinguish "safe to type" from "typing will queue," producing confusing one-prompt-behind lag that feels like the session is stuck. This hits any long-lived background process — relays/watchers, long shell jobs, parallel subagents.

Request: Surface two visually distinct states:

• Generating… (animated,  isProcessing  true) — "typing will queue."
• Idle · N background task(s) (calm,  hasActiveBackgroundWork  only) — "safe to type, runs immediately."

Reserve the  Queued (N)  indicator for genuine mid-turn queuing. This removes the ambiguity and makes background processes usable without UX surprise.

### Affected version

v1.0.64-1

### Steps to reproduce the behavior

Environment:

• GitHub Copilot CLI v1.0.64-1 (also reproduces on any build with background subagents/shell tasks)
• OS: Windows 11 (platform-independent)

Preconditions: A Copilot CLI interactive session.

Steps to reproduce (primary — cosmetic busy state):

1. In the session, trigger a long-lived background process. Either:
• (a) Ask Copilot to start a background subagent that idles ~90s (e.g. a task that runs  Start-Sleep -Seconds 90 ), or
• (b) Run a shell command and move it to the background with  ctrl+x → b  (e.g. a 90s sleep).
2. Wait until Copilot's own turn has fully completed — the response has stopped streaming and the token/response-size counter is static. The agent is now idle (not generating).
3. Observe the status line: it shows "Working" / "Waiting for background agents."
4. While in that state, type a prompt (e.g.  ping ) and press Enter once.

Expected: Status should indicate the agent is idle and safe to type (background work is separate).

Actual: Status says "Working/Waiting for background agents" (implying don't type), yet the prompt goes pending and runs immediately on one Enter — proving input was never blocked. The busy status is cosmetic and contradicts actual behavior.

Steps to reproduce (secondary — sticky N-1 queue, related):

1. While Copilot is actively generating a response, type a prompt and press Enter → it shows  Queued (N)  instead of running.
2. Keep typing prompts during each subsequent generation. Each Enter submits the previous queued prompt and queues the current one → you remain perpetually one prompt behind (N-1).
3. The lag only clears if you stop typing and let the queue drain, or press Enter on an empty line to flush the held prompt.

Expected: A clear, distinct visual for "actively generating (typing will queue)" vs "idle with background work (safe to type)," and a way to tell you've fallen into the N-1 queue.

Root cause (from app.js):

• Busy indicator is driven by  hasActiveWork = isProcessing || hasActiveBackgroundWork()  ( hasActiveBackgroundWork()  = running subagents or running attached shell commands).
• The "Waiting for background agents" string is state  currentIntent / YP , consumed only by the terminal title ( MOn ) and the status-line display component — it does not gate input.
• The real input gate is  isProcessing  (parent mid-turn) only. Hence the mismatch: background work flips the display to busy while input stays functionally free.

Suggested fix: Distinguish Generating… ( isProcessing , animated, "typing queues") from Idle · N background task(s) ( hasActiveBackgroundWork  only, calm, "safe to type"). Reserve  Queued (N)  for genuine mid-turn queuing.

### Expected behavior

_No response_

### Additional context

_No response_

Start in app.js and trace hasActiveWork, isProcessing, hasActiveBackgroundWork(), currentIntent, and the Queued indicator. Reproduce both an active generation and an idle session with a background task, then verify the status line distinguishes generating from idle background work and that genuine mid-turn queueing remains identifiable.

Written by the indexing model from the issue text.