[dotnet-port-api] Response.ModelID and ConversationID fields

[PratikDhanave]

Parity gap surfaced comparing agent.Response.Update against M.E.AI ChatResponseExtensions.ProcessUpdate.

Gap

ProcessUpdate folds two update fields onto the response that Go has no home for:

• update.ModelId → response.ModelId
• update.ConversationId → response.ConversationId

Go's agent.Response has neither ModelID nor ConversationID. Today the model id is only surfaced ad hoc via provider AdditionalProperties (e.g. the recent Copilot usage model and OpenAI paths), and conversation identity lives on Session.ServiceID. So there is no canonical, provider-agnostic way to read "which model produced this response" or "which server-side conversation it belongs to."

Reference

• M.E.AI ChatResponse.ModelId / ChatResponse.ConversationId, folded in ChatResponseExtensions.ProcessUpdate.
• ChatResponseUpdate.ModelId / .ConversationId.

Proposed shape (needs maintainer input)

Add ModelID string (and possibly ConversationID string) to agent.Response and agent.ResponseUpdate, and fold them in Response.Update the same way ResponseID/FinishReason are folded (prefer later non-empty values). Providers would populate ResponseUpdate.ModelID from the model on the response.

Open questions:

1. Scope: ModelID alone (smaller, immediately useful) vs also ConversationID (overlaps Session.ServiceID — may be redundant in Go).
2. Whether providers should stop stashing model in AdditionalProperties once a first-class field exists (migration/back-compat).

Filing issue-first per CONTRIBUTING (new public API). Note #1133 fixes the related AdditionalProperties scoping bug in the same Response.Update, independent of this proposal.