ctrl+x → b  fails to background/interrupt a blocking  read_bash  call (no escape hatch when polling an async command)

### Describe the bug

ctrl+x → b  ("move current task to background") does not work when the agent is blocked inside a  read_bash  call with a nonzero  delay , even though the underlying shell command was already started with  mode: "async" .

Repro: agent runs  bash { command, mode: "async" }  to start a long command, then calls  read_bash { shellId, delay: 150 }  to wait on it. Pressing  ctrl+x → b  during that 150s wait returns "No running sync task to move to background." There is no way to interrupt or background this — the session appears frozen with no escape hatch, which is worse than a plain  mode: "sync"  call (which presumably is backgroundable via the same keybind).

Expected:  ctrl+x → b  should also detect and background/interrupt a blocking  read_bash  (or any tool call) that's been running past some threshold, not just a live  bash mode=sync  invocation.

### Affected version

GitHub Copilot CLI 1.0.70.

### Steps to reproduce the behavior

1. Start a Copilot CLI session.
2. Have the agent run a shell command in background mode, e.g. equivalent of:
bash { command: "sleep 150", mode: "async" }
``` This returns a `shellId` immediately (command is now running detached in the background). ```
3. Immediately have the agent call:
read_bash { shellId: , delay: 150 }
``` This blocks the agent's tool call — and the interactive session — for the full 150 seconds while it waits to read output. ```
4. While that  read_bash  call is still pending/blocking (i.e., before the 150s elapses and before the agent's turn produces any further output), press  ctrl+x → b  to try to move the current task to background.

### Expected behavior

The current task (the agent's blocked turn) is moved to background, session control returns to the user, and the job can be checked later via  /tasks .

### Additional context

Actual result: The keybind reports "No running sync task to move to background" — even though the session is visibly blocked/unresponsive for the full 150-second duration. There is no live, backgroundable "task" for the CLI to detect, because the underlying shell command ( sleep 150 ) was already async — only the agent's read_bash  wait is blocking, and that isn't recognized as a task the keybind can act on.

Additional note: This was verified in contrast to a (not yet independently confirmed, but documented-as-working) genuine  bash mode="sync"  call — the bug is specific to the  read_bash -poll blocking pattern, which is the more dangerous case since it currently has no user-facing escape hatch at all.

Start at the ctrl+x → b keybind handling and trace how it identifies a running task; then follow the read_bash path for a nonzero delay after bash mode="async" returns a shellId. Reproduce with sleep 150 and delay 150. Done when the blocked turn can be moved to background, control returns, and it appears under /tasks without the current error.

Written by the indexing model from the issue text.