Asking to list open sessions on a follow-up turn reliably breaks Agent Host session (Error: query - No response was returned)

- Copilot Chat Extension Version: (see Help > About in VS Code, or Report Issue auto-fill)
- VS Code Version: (see Help > About)
- OS Version: Windows
- Feature: Agent mode / Agents window sessions (Agent Host)
- Selected model: Claude Sonnet (also reproduced regardless of model)
- Logs: Two "Developer: Export Agent Host Debug Logs..." bundles were captured showing this failure; happy to attach/share on request.

## Summary

In an active Agent Host chat session, sending a message that asks the assistant to list currently open/running sessions (i.e. triggering the `list_sessions` tool/intent) as a non-first turn reliably causes that turn to fail with an empty model response, surfaced to the user as:

```
Error: (query) No response was returned. Send your message again to retry.
```

Once a session enters this state, resending the identical message does **not** recover it (also fails). The only recovery observed is restoring a checkpoint to before the failing turn.

## Steps to Reproduce

1. Start a new chat session (Agent mode). Send any innocuous first message (e.g. "Say hello."). Confirm it completes normally.
2. As the very next message in the same session, ask the assistant to list all currently open/running sessions (e.g. "List all the currently open sessions.").
3. Observe the turn fails immediately with `Error: (query) No response was returned. Send your message again to retry.`
4. Resend the identical message — it fails again.
5. Restore a checkpoint to before the failing turn — the session recovers and behaves normally again.

## Reproduction rate / isolation testing performed

- 3/3 reproductions across separate fresh sessions when turn 2 asked to list sessions (varying exact phrasing), all with the model explicitly set to Claude Sonnet.
- 2/2 control sessions succeeded normally when turn 2 asked an unrelated question instead (e.g. simple math, trivia), on otherwise identical fresh sessions/model — this isolates the trigger to the session-listing request itself, not to turn position or to the model.
- Reproduced identically with all MCP servers disabled, which rules out MCP server startup/latency/failures as the cause.
- In every failure observed (both live repro and in two historical Agent Host debug log exports), the response comes back with 0 characters of content and **no tool call is recorded before the error** — i.e., the failure appears to happen before/during resolving the request, not inside actual tool execution (real `list_sessions` tool invocations found in the historical logs completed successfully with no error).
- Also observed, separately, that background MCP/tool inventory can be reloaded live during an active session (e.g. an MCP server that was stopped got restarted mid-session without user action, and the assistant's available tool list changed mid-session) — this may or may not be related, but is a live oddity in the same environment worth investigating alongside this.

## Likely error source

The user-visible error text originates from a guard that classifies HTTP-200-but-empty-content model responses as `errorType: 'query'` in the Agent Host's Copilot session handling code (src/vs/platform/agentHost/node/copilot/copilotAgentSession.ts, introduced around PR #334818). That `errorType` is an intentionally-generic/unclassified catch-all, so this specific trigger (asking to list sessions) may just be the most reliable way found so far to reproduce one cause bucketed under that same generic error.