Emit explicit message item types in Responses API serializer

[jimstrang]

Summary

Fixes #318125.

Adds explicit type: 'message' fields when converting user/system message items to the OpenAI Responses API input format.

I found this while validating the Azure BYOK work in #318118, tracked by #318110, #318111, and #318114. Once the auth/provider/scope pieces were working, the newer Azure AI Foundry openai/v1/responses style endpoint exposed a shared request-shape bug: user/system Responses input items were missing the explicit type: 'message' discriminator and failed with invalid_value for input[1].

This updates the shared Responses API serializer so that:

• Raw.ChatRole.User emits { type: 'message', role: 'user', ... }
• Raw.ChatRole.System emits { type: 'message', role: 'system', ... }
• tool-result image follow-up messages emit { type: 'message', role: 'user', ... }

Some Responses-compatible backends are strict about message item shape and reject input items that omit the type discriminator, even when role and content are present.

Validation

Automated tests:

• Focused Responses API tests passed:
  • responsesApi.spec.ts
  • responsesApiToolSearch.spec.ts
  • 53 passed
• Full endpoint node test slice passed:
  • 108 passed

Live validation:

• Default signed-in Copilot Responses path:

  • Tested GPT-5.5
  • Confirmed Raw.ChatRole.System and Raw.ChatRole.User both reached the shared Responses serializer with explicit type: 'message'
  • Requests completed successfully, including panel chat and conversation-history summarization paths

• Azure Government BYOK Responses path:

  • Tested an Azure Government Responses deployment using sovereign Microsoft auth
  • Confirmed Raw.ChatRole.System and Raw.ChatRole.User message serialization
  • Requests completed successfully

• Azure AI Foundry BYOK Responses path:

  • Tested a commercial Azure AI Foundry openai/v1/responses style endpoint using Microsoft auth
  • Confirmed Raw.ChatRole.System and Raw.ChatRole.User message serialization
  • Requests completed successfully

• OpenAI-compatible non-Azure BYOK Responses path:

  • Tested a custom OpenAI-compatible Responses endpoint using customendpoint with apiType: responses
  • Confirmed Raw.ChatRole.System and Raw.ChatRole.User message serialization
  • Requests completed successfully

• Tool-result image follow-up path:

  • Confirmed the asImages.length branch emitted an explicit type: 'message' user follow-up item
  • This covers the third changed message emission path

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR updates the Responses API request body generation to emit explicit type: 'message' for user/system message inputs (and for user messages synthesized from tool-result images), and adds/updates tests to lock in the new wire format.

Changes:

• Add tests asserting type: 'message' is emitted for system/user inputs and for tool-result image attachment messages.
• Update existing tests to include type: 'message' in expectations for sliced inputs.
• Update request-body construction to always include type: 'message' for user/system message items.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
extensions/copilot/src/platform/endpoint/node/test/responsesApi.spec.ts	Adds/updates unit tests to validate explicit type: 'message' in request input items.
extensions/copilot/src/platform/endpoint/node/responsesApi.ts	Ensures generated Responses API input items for system/user messages include type: 'message'.