Responses API should support native `previous_response_id` chaining

### Summary

When using the Copilot SDK/CLI with the Responses API, every model round reconstructs and sends the complete conversation history. The runtime does not send `previous_response_id` and sets `store: false`.

This substantially increases request tokens for long-running and resumed sessions.

### Versions tested

- `GitHub.Copilot.SDK` 1.0.5 with Copilot CLI 1.0.73
- `GitHub.Copilot.SDK` 1.0.9-preview.1 with Copilot CLI 1.0.74
- Azure AI Foundry OpenAI-compatible provider
- `wireApi: responses`

The preview SDK references CLI `1.0.76-5`, but that package was not available for testing.

### Observed behavior

A privacy-safe request probe showed:

- Initial request: 1 input item
- Tool continuation: 3 input items
- Next user turn: 5 input items
- Resumed session in a new process: 7 input items

No request included `previous_response_id`. The runtime also emitted `store: false`.

In a real long-running session, this resulted in approximately 26K–28K reported input tokens per request, including tool continuations.

### Expected behavior

After the initial Responses request:

1. Set `store: true`, or otherwise use provider-supported response retention.
2. Capture the terminal response ID.
3. Send subsequent model rounds with:
- `previous_response_id`
- only newly added input items
4. Preserve instructions, tools, and request settings as required by the Responses API.
5. Fall back to full history if the provider rejects or cannot resolve the response ID.

This should apply to both tool-result continuations and subsequent user turns.

### Workaround validation

We implemented an experimental request handler that:

- changes `store: false` to `store: true`,
- captures IDs from terminal SSE response events,
- adds `previous_response_id`,
- replaces reconstructed history with incremental input,
- falls back to full history when chaining cannot be verified.

Live validation reduced:

- a tool continuation from 60 input items to 1,
- a subsequent user turn from 66 input items to 1.

Conversation context and tool behavior remained correct.

The handler also had to account for non-semantic differences when the CLI reconstructed response items:

- regenerated top-level response item `id`,
- omitted assistant-message `phase`,
- omitted output-text `logprobs`.

Semantic content and tool `call_id` values were still compared exactly.

### Request

Could native Responses API chaining be added to the Copilot CLI/runtime and exposed or enabled through the SDK?

It would also be useful to clarify:

- whether the SDK’s `PreviousResponseId` protocol field is currently used by any provider path,
- how response IDs should persist across SDK session resumes or process restarts,
- whether token telemetry can report the actual rewritten wire input rather than reconstructed local history.

首先跟踪 Responses API 的请求路径和 SDK 的协议字段 PreviousResponseId，然后比较工具延续、后续用户轮次和恢复的会话。完成标准是：受支持的提供商使用保留的响应 ID 和增量输入，保留必要的设置，在链接失败时回退到完整历史记录，并确保上下文和工具行为正确。

由索引模型根据 Issue 内容生成。