[BUG] Main session: text-only assistant turn after action-requesting user message ends turn silently with no auto-continue (1.0.4x regression)

### Describe the bug

**Severity: serious regression in 1.0.4x.** The CLI agent silently ends a turn with a text-only assistant response (no tool calls) when the preceding user message clearly requires action. The CLI does not auto-continue, does not warn the user that the agent has stalled, and does not nudge the model. The user is left staring at an idle prompt for an arbitrary number of minutes (22 minutes in our worst case today) until they manually re-prompt with something like "Why are not job acting even after I asked u to work" — at which point the next assistant turn opens with "Sorry, I started thinking and never sent a tool call." This wastes premium-request budget, blocks downstream work, and corrodes trust in the agent's reliability for long unattended workflows.

This is the same underlying root mechanism as #2949 (text-only assistant turn on a model that was supposed to act), but the scope is different: that issue is about MCP teardown in background agents. This issue is about the **main session** treating a text-only turn as a valid stopping point when it is not.

### Affected version

| | |
|---|---|
| **Copilot CLI** | `1.0.44` |
| **Node** | `v25.8.0` |
| **OS** | `Darwin MacBook-Pro.local 25.4.0 arm64` (macOS 15.x) |
| **Model** | `Claude Opus 4.7 (1M context)(Internal only)` (model ID `claude-opus-4.7-1m-internal`) |
| **Session ID** | `91a3e786-46c8-45ca-a405-86cc3dab2156` |
| **events.jsonl size** | ~78 MB at time of repro |
| **Session length** | ~6.5 hours, 100+ tool calls, multi-step firmware deployment |

### User-visible symptom

> "Hope u fixed all identified bug on i2c automation and then only copied/ran?"
>
> [agent works, replies, asks user a question]
>
> User (16:31 PT): "Can you at-least complete Unit testing now and push the changes without deployment as run is going ON?"
>
> [22 minutes pass with the CLI showing the model as idle, no spinner, no warning]
>
> User (16:53 PT): "What are you doing? Why are not job acting even after I asked u to work"
>
> Agent (next turn opens): "Sorry, I started thinking and never sent a tool call. Working now."

### Smoking-gun log evidence

From this session's `~/.copilot/logs/process-1778433883305-26214.log`:

```
2026-05-10T23:31:19.055Z [DEBUG] response (Request-ID 00000-62fd5594-3471-4e03-bcf2-11d63235132f):
^ user message arrives ("Can you at-least complete Unit testing now...")

2026-05-10T23:31:41.846Z [DEBUG] response (Request-ID null):
^ assistant streaming response begins

## NOTE: NO "[DEBUG] Tool calls count: N" line follows.
## On every other healthy turn in this same log this line appears < 5 ms after.

2026-05-10T23:31:41.847Z [DEBUG] Ignoring event of kind: response
2026-05-10T23:31:41.848Z [DEBUG] Ignoring event of kind: messages_snapshot
^ harness accepts the empty turn as terminal and drops back to interactive prompt.
^ no auto-continue, no UI banner, no telemetry warning.
```

After this point the next assistant log line is at 2026-05-11T00:00:42 UTC, when the user manually nudged.

### Frequency in a single 6.5h session

Counted with this filter on the same log: every `response (Request-ID null)` line followed by `Ignoring event of kind: response` with **no** `Tool calls count:` line between them.

```
2026-05-10T19:57:30.295Z
2026-05-10T20:00:55.483Z
2026-05-10T20:25:24.371Z
2026-05-10T20:29:44.974Z
2026-05-10T21:12:39.421Z
2026-05-10T22:05:50.492Z
2026-05-10T23:31:41.846Z <- the one that caused the 22-minute stall
```

**7 text-only assistant turns in 6.5 hours = ~1 per hour.** Some of these may be legitimate "task complete, awaiting next instruction" turns. The 23:31:41 one was demonstrably not — the user message immediately preceding it was a clear directive ("Can you at-least complete Unit testing now and push the changes...").

### Steps to reproduce

The harness behaviour is deterministic given a model that produces a text-only turn. To reproduce reliably:

1. Use a long-running session (the bug rate goes up the more system instructions and skill text are loaded; #2949 reports 100% rate when the system prompt encourages reasoning).
2. Have a `~/.copilot/copilot-instructions.md` or `AGENTS.md` that enforces "REASON THOROUGHLY" / "no brevity over quality" style hard rules. (Our personal rules file does exactly this.)
3. Send a multi-step user request after the agent has been working for a while.
4. Watch for the agent occasionally responding with a single thinking-style paragraph and then stopping with no tool call.

### Expected behaviour

When the LLM produces a text-only assistant turn AND the preceding user message clearly requested an action, the harness should do **at least one of**:

1. **Auto-continue.** Synthesise an internal nudge ("Continue with the user's last request. The previous response had no tool calls.") and re-issue the request. This is what the underlying coding-agent harness does in some of GitHub's own products.
2. **Surface a clear UI banner.** "Agent produced a text-only response. Press Enter to nudge or type a follow-up." Today there is silence; the user has no signal that the agent has stalled.
3. **Telemetry warning.** Emit a `text_only_turn_after_action_request` event so this can be measured and tracked across releases.

The current behaviour treats every text-only turn as a valid stop, which is wrong for the dominant use case (the user wants the agent to keep working until done).

### Possible regression cause

This pattern was less frequent in earlier 1.0.x versions. Two recent changes worth investigating:

1. The `Ignoring event of kind: response` / `Ignoring event of kind: messages_snapshot` pattern is new in the 1.0.3x/1.0.4x line. The same event sequence is implicated in #2949 for background-agent MCP teardown. The handler that "ignores" these events appears to have replaced an older path that would have re-prompted the model on an empty turn.
2. The Opus 4.7 + 1M-context model addition coincides with this bug becoming user-visible. Bigger context -> more system-prompt-driven reasoning -> higher rate of text-only turns. The model side may not change, but the harness must still cope.

### Why this matters

The reasoning models actively prompt the LLM to think before acting. The harness must accept that text-only turns will occasionally happen, and must NOT treat them as terminal. Today every text-only turn = a guaranteed user-driven nudge later, which is:

- A wasted premium request (the nudge counts).
- 5 to 30 minutes of human idle time per occurrence (this user's typical re-check interval).
- A trust hit that compounds across hours: "Why is this thing not working?" leads users to abandon long workflows.

### Related issues

- #2949 — same root mechanism (text-only assistant turn) but the symptom there is MCP teardown in background agents. Worth coordinating fixes since both paths handle the `Ignoring event of kind: response` codepath.
- #2172 — compaction agent sometimes stalls after replying. Possibly a related text-only-turn stall in a different code path.
- #286 — non-interactive prompt sometimes exits without acting. Possibly related early form of the same bug.

### Suggested labels

`bug` · `regression` · `area:agents` · `area:sessions`

### Ask

1. Treat a text-only assistant turn that follows an action-requesting user message as a stall, not a stop. Auto-continue with a synthetic nudge.
2. Surface a visible UI indicator in the TUI when this happens, so the user can see the stall and act on it.
3. Emit telemetry so the rate of this bug can be tracked across releases.
4. Coordinate with the fix for #2949 since both touch the same `Ignoring event of kind: response` path.

Commencez par la séquence d’événements dans ~/.copilot/logs/process-1778433883305-26214.log, en particulier le chemin `Ignoring event of kind: response` et l’absence de la ligne `Tool calls count` ; comparez-la à l’issue associée #2949. C’est terminé lorsqu’un message utilisateur demandant une action, suivi d’un tour de l’assistant contenant uniquement du texte, ne se termine plus silencieusement, et que le comportement sélectionné de continuation, d’UI ou de télémétrie est couvert de manière démontrable.

Rédigé par le modèle d'indexation à partir du texte de l'issue.