Custom Endpoint: switching an existing Chat Completions conversation to Responses API produces invalid input payload

## Bug: Switching a conversation from Chat Completions to Responses API fails for Custom Endpoint models

### VS Code version

VS Code: 1.133.0 x64
OS: Garuda Linux x86_64 (Linux .1.8)
Copilot Chat: bundled with VS Code

### Feature

GitHub Copilot Chat → Custom Endpoint / BYOK

### Model

Custom Azure AI Foundry deployment:

gpt-5.6-luna

The model is deployed through Azure AI Foundry and supports both Chat Completions and Responses.

### Configuration

The model is configured as a custom endpoint with:

```json
{
"id": "gpt-5.6-luna",
"name": "Gpt 5.6 Luna",
"url": "https:///api/projects//openai/v1/responses",
"apiType": "responses",
"toolCalling": true,
"vision": true,
"maxInputTokens": 878000,
"maxOutputTokens": 128000,
"supportsReasoningEffort": [
"low",
"medium",
"high"
],
"reasoningEffortFormat": "responses",
"streaming": true,
"zeroDataRetentionEnabled": true
}
````

### Expected behavior

I should be able to switch from a Custom Endpoint model using the Chat Completions API to a Custom Endpoint model using the Responses API while keeping the existing conversation history.

VS Code should convert the existing conversation history into a valid Responses API `input` representation.

### Actual behavior

A fresh chat works correctly with the Responses endpoint.

However, if an existing conversation contains previous turns generated using a Chat Completions custom endpoint, switching the model to the Responses-based model fails.

The Responses request reaches Azure successfully but Azure rejects the generated historical input payload.

The first error was:

```text
400 invalid_payload

Required property 'annotations' is missing

param:
input[3].content[0].annotations
```

The same error occurred for many historical input positions:

input[3], input[5], input[10], input[12], etc.

This indicates that VS Code is generating Responses API input content from the existing Chat Completions history without including fields required by the Responses representation.

### Additional testing

I confirmed that the Azure Responses endpoint itself works independently of VS Code.

A direct request to:

```text
https:///api/projects//openai/v1/responses
```

with:

```json
{
"model": "gpt-5.6-luna",
"input": "Hello"
}
```

returns HTTP 200.

Tool calling also works directly through the Responses endpoint.

For example, the Responses API correctly returns:

```json
{
"type": "function_call",
"name": "get_weather",
"arguments": "{\"city\":\"London\"}",
"status": "completed"
}
```

Therefore this does not appear to be an Azure/model compatibility problem.

### Important observation

When I attempted to work around the first validation error by adding:

```json
"annotations": []
```

to every `input[*].content[*]` object, Azure then returned:

```text
400 invalid_request_error

Unknown parameter:
input[0].content[0].annotations
```

This suggests that VS Code is producing a content representation that is not being correctly converted for the Responses API.

The issue appears specifically related to converting/replaying historical Chat Completions messages when the selected model uses the Responses API.

### Reproduction steps

1. Configure a Custom Endpoint Chat Completions model.
2. Start a conversation.
3. Use the model for multiple turns.
4. Allow the conversation to contain tool calls/tool results.
5. Switch the model in the same conversation to a Custom Endpoint model configured with:
`apiType: "responses"`.
6. Send another message.
7. Observe the 400 error.

### Control test

Start a completely new conversation with the same Responses model.

Result:

SUCCESS — HTTP 200.

Therefore:

Fresh conversation → Responses model → works

Existing Chat Completions conversation → switch to Responses model → fails

### Relevant error

```text
Invalid payload: Required property 'annotations' is missing

param:
input[3].content[0].annotations
```

### Expected

VS Code should either:

1. correctly normalize the existing Chat Completions history into the Responses API input format when switching API types, or
2. prevent switching between incompatible API representations for an existing conversation and clearly indicate that a new conversation is required.

Ideally, existing conversation history should be converted automatically.

### Impact

This prevents users from switching to a stronger Responses-based reasoning model in an ongoing Agent conversation when the previous turns were generated through a Chat Completions custom endpoint.

This is particularly problematic for BYOK/custom Azure AI Foundry deployments where different models may expose different API types.