Resumed session retains stale connection item IDs after interrupted response

Describe the bug

After reopening and resuming an existing Copilot CLI session, every prompt fails with:

Execution failed: CAPIError: 400 input item ID does not belong to this connection

The affected session does not recover after retrying. Forking it with /fork also does not help: prompts in the fork fail with the same error. A separate new Copilot CLI session works normally.

This appears to be a regression of #2147, which was closed as fixed in v1.0.10. The reported root cause there was stale WebSocket state being reused after a reconnection.

Affected version

GitHub Copilot CLI 1.0.81-0

Steps to reproduce the behavior

I am not certain of the exact trigger, but the likely sequence was:

1. Use an existing Copilot CLI session normally.

2. Exit or close the CLI while the agent is about to respond or while a response is in progress.

3. Reopen Copilot CLI and resume the existing session.

4. Enter a prompt such as continue.

5. Observe:

   Execution failed: CAPIError: 400 input item ID does not belong to this connection
   (Request ID: 00000-ed11ed35-1761-4d58-95f1-7f22a29c4556)
   

6. Retry the prompt and receive the same error with a new request ID:

   Execution failed: CAPIError: 400 input item ID does not belong to this connection
   (Request ID: 00000-b4c9a489-fc2f-4b5f-921f-13a2e409f386)
   

7. Run /fork and try another prompt in the fork. The error persists.

8. Start a separate new session. The new session works normally.

Expected behavior

Copilot CLI should discard or reconstruct connection-bound response state after reconnecting. An interrupted response should not permanently make a persisted session, or a fork of that session, unusable.

Additional context

• Operating system: Windows
• CPU architecture: ARM64
• Shell: PowerShell 7
• The original session log shows the old Copilot process shutting down and cleaning up the persisted session before it was reopened.
• The failure is isolated to the affected conversation and forks made from it.
• Restarting/reconnecting and retrying do not recover the conversation.
• A comment on #2147 reports the same failure on v1.0.79-4, suggesting the issue may have regressed before v1.0.81-0.
• I have not attached the complete session log because it contains conversation and tool history.

Investigated and filed with assistance from GitHub Copilot CLI.

No source file or test is named. Start by tracing the resume/reconnection flow for a persisted session, including the /fork path and cleanup after an interrupted response; use the reported reproduction sequence and session log context to locate reused connection-bound state. Done means resumed sessions and their forks no longer fail with the stale input item ID error, while new sessions continue to work.