Problem

Fixes microsoft/agent-framework#5189

FunctionInvokingChatClient.ExtractAndRemoveApprovalRequestsAndResponses throws InvalidOperationException when conversation history contains a ToolApprovalRequestContent (TARC) / ToolApprovalResponseContent (TAResp) pair whose FunctionCallContent objects have inconsistent InformationalOnly flags — a situation that reliably occurs after session serialization/deserialization.

Root Cause

FICC relies on shared object references between the FunctionCallContent (FCC) inside a TARC and the FCC inside the corresponding TAResp. When GenerateRejectedFunctionResults sets FCC.InformationalOnly = true, it only mutates the TAResp's FCC. Without serialization this works because TARC and TAResp share the same FCC object. After serialization, they are separate instances and the TARC's FCC retains InformationalOnly = false.

Turn-by-turn reproduction

Turn 1 — User sends a message. Model returns FunctionCallContent("call1"). FICC wraps it in ToolApprovalRequestContent and returns it. End-of-run persistence stores [user_msg, TARC(FCC)].

Session serialize → deserialize — The stored TARC now contains a new FCC object (FCC_D, InformationalOnly = false). The caller still holds the original FCC (FCC_OLD) from the response.

Turn 2 — User rejects the approval using the original TARC reference, creating TAResp(FCC_OLD). Messages sent to FICC:

FICC processes successfully — both match the InformationalOnly: false pattern. GenerateRejectedFunctionResults sets FCC_OLD.InformationalOnly = true. But FCC_D is a different object and is NOT mutated. Model retries → returns new FCC("call2") → wrapped in TARC2.

End-of-run persistence stores:

Turn 3 — User rejects call2. FICC's ExtractAndRemoveApprovalRequestsAndResponses processes history:

1. TARC(FCC_D, InformationalOnly=false) → matches pattern → adds "call1" to approvalRequestCallIds
2. TAResp(FCC_OLD, InformationalOnly=true) → SKIPPED (doesn't match InformationalOnly: false guard)
3. TARC2(call2, InformationalOnly=false) → matches → adds "call2"
4. TAResp2(call2, InformationalOnly=false) → matches → removes "call2"

Result: approvalRequestCallIds = {"call1"} — validation throws:

InvalidOperationException: ToolApprovalRequestContent found with FunctionCall.CallId(s) 'call1' 
that have no matching ToolApprovalResponseContent.

Fix

Mark both the request and response FunctionCallContent as InformationalOnly = true at every approval processing point, ensuring consistency regardless of object identity:

1. ApprovalResultWithRequestMessage — Now stores the ToolApprovalRequestContent alongside the response, exposing both ResponseFunctionCallContent and RequestFunctionCallContent.

2. ExtractAndRemoveApprovalRequestsAndResponses — The approval request dictionary now stores the TARC content alongside the message, and passes it through to ApprovalResultWithRequestMessage.Request.

3. GenerateRejectedFunctionResults — Marks both ResponseFunctionCallContent and RequestFunctionCallContent as InformationalOnly = true.

4. InvokeApprovedFunctionApprovalResponsesAsync — Also marks the request FCC for the approved path, since the same identity split exists after serialization.

5. Tests — CloneInput now deep-clones FunctionCallContent, ToolApprovalRequestContent, and ToolApprovalResponseContent, simulating the serialization effect (separate FCC instances) so existing tests exercise the previously broken codepath.

CC @stephentoub