[dotnet-port] Align tool approval response snapshots

[qmuntal]

Snapshot tool-call content when creating approval responses so the approved call remains stable if the original request content is mutated before execution or serialization. This mirrors the upstream .NET workflow approval snapshot behavior from microsoft/agent-framework#6427.

[Copilot]

Pull request overview

This PR updates tool-approval response creation to snapshot (clone) tool-call content and relevant headers at the time the approval response is created, so later mutations to the original request/tool-call object don’t change what ultimately gets approved/serialized—aligning behavior with the referenced upstream .NET workflow.

Changes:

• Clone ToolApprovalRequestContent.ToolCall when building an approval response to make approvals stable against later mutations.
• Clone ContentHeader.AdditionalProperties and Annotations when building approval responses.
• Add tests validating snapshot behavior for both FunctionCallContent and MCPServerToolCallContent.

Show a summary per file

File	Description
message/content.go	Clones tool-call content and header fields when creating tool-approval responses.
message/content_test.go	Adds tests ensuring approval responses are unaffected by subsequent mutations to the original tool call/request.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 2/2 changed files
• Comments generated: 2

[github-actions]

API Consistency Review: ✅ Aligned

Changed surface: (*ToolApprovalRequestContent).CreateResponse in message/content.go

What changed: CreateResponse now defensively clones the ToolCall content and shallow-copies ContentHeader.AdditionalProperties and Annotations into the returned ToolApprovalResponseContent, ensuring the approval response is stable if the caller mutates the original request object after calling this method. The PR also fixes a latent gap where Annotations and RawRepresentation were silently dropped from the response's ContentHeader.

Parity check vs .NET (microsoft/agent-framework):

The referenced upstream PR #6427 added snapshot behavior at the declarative executor layer (InvokeFunctionToolExecutor), persisting evaluated function parameters to workflow state before a checkpoint so they survive restore cycles. That is a different, complementary mechanism. The underlying ToolApprovalRequestContent.CreateResponse in .NET (from Microsoft.Extensions.AI) does not itself clone the ToolCall — the Go SDK is choosing to enforce copy isolation one level lower (at the factory method), which is both a valid Go idiom and consistent with the semantic goal (approved tool-call state must not change after approval is issued).

Parity check vs Python (microsoft/agent-framework):

Python does not have a ToolApproval harness equivalent in the framework today. No divergence to flag.

No parity issues found. The implementation approach is intentionally language-idiomatic (Go value-copy semantics, maps.Clone/slices.Clone) and semantically aligned with the .NET snapshot intent.

Generated by Go API Consistency Review Agent for issue #279 · sonnet46 1.9M · ◷