Agent Host stops forwarding turn events after screenshot tool returns an image

- Copilot Chat Extension Version: Built-in Agent Host; Copilot runtime 1.0.84-canary.70.gdb75d0d.unsigned
- VS Code Version: 1.137.0-insider (645f29cc3176500b4b5762ba887cf2a7f0ffdf2c)
- OS Version: macOS, arm64
- Feature: Agents Window / Agent Host
- Selected model: GPT-5.6 Sol
- Logs: Two Agent Host debug bundles captured; available privately on request

## Summary

After a browser `screenshotPage` tool successfully returns an image, Agent Host stops forwarding subsequent Copilot SDK events to AHP. The SDK continues running and completes the task, but the UI remains indefinitely on **Loading** because it never receives the later response parts or `chat/turnComplete`.

This has reproduced twice in the same session. The second capture is a clean reproduction with no steering, chat navigation, or subscription disposal.

## Steps to Reproduce

1. Start an Agent Host task that uses the integrated browser.
2. Have the agent call `screenshotPage` so the tool returns an image for model inspection.
3. Observe that the screenshot appears in the response.
4. Wait for the agent to continue.

## Expected

Events after the image-bearing tool result continue to stream to AHP. The UI shows subsequent progress/final response and receives `chat/turnComplete`.

## Actual

The screenshot tool completes and its image is shown, but the UI remains on **Loading**. Persisted SDK events prove that the agent continues through validation, commit, and a final answer. AHP emits no further response or lifecycle events for the request after the screenshot boundary.

## Correlated timeline from the clean reproduction

Pacific time, 2026-09-09:

- `08:35:40.588` — AHP delivers progress: `Reviewing catalog combination`.
- `08:35:41.495` — SDK starts `screenshotPage`.
- `08:35:41.576` — SDK records successful completion with a 59,939-byte JPEG asset.
- `08:35:41.578` — AHP delivers `chat/toolCallComplete` for the screenshot.
- `08:35:41.840` — AHP delivers the last observed `chat/usage` action.
- **AHP then emits no more response/tool/turn-completion actions for request `request_e29a7e78-0dc8-4095-9a2a-d9d3c55a0bb1`.**
- `08:35:41.728` — SDK ends the screenshot subturn and starts the next subturn.
- `08:35:53.111` — SDK sends further progress and starts final checks.
- `08:35:54.541` — checks complete successfully.
- `08:36:11.255` — commit completes successfully.
- `08:36:20.157` — SDK produces the final answer.
- `08:36:20.160` — SDK records the final turn ending.

The UI never receives these later events or `chat/turnComplete`.

## Secondary failure when steering the stuck turn

In an earlier reproduction, sending a steering message after the image stall cancelled the old request and released its buffered SDK events. Those old events were incorrectly attributed to the new AHP request, causing the new request to complete with the old answer. The actual new interaction was processed by the SDK, but its later AHP events had no request/turn ID and were effectively ignored by the UI.

This suggests two connected problems:

1. SDK-to-AHP event forwarding stalls after an image-bearing tool result.
2. Cancellation/steering after the stall can rebind buffered events to the wrong request.

## Notes

The clean reproduction rules out the model, screenshot generation, user steering, New Chat navigation, and early subscription disposal as the primary cause. The screenshot itself succeeds and reaches both the SDK and UI; forwarding fails immediately afterward.