Motivation & Context

Approving a run_skill_script tool call in the Agent Inspector left the function
call unanswered: the tool block showed a red ✗ and the next conversation turn was
rejected by the Responses API with
400 - No tool output found for function call call_<id>.

The same defect affects any approval round-trip served through a hosting layer,
not just skills — SkillsProvider is simply the configuration that surfaces it,
because it puts an approval-gated tool on the default path.

Description & Review Guide

• What are the major changes?

  One scoping fix in _replace_approval_contents_with_results
  (python/packages/core/agent_framework/_tools.py).

  The function restores a function_call from its function_approval_request
  wrapper, deduping against calls already present so it does not add a second
  copy. That dedupe set was rebuilt inside the per-message loop, so it only ever
  saw the message currently being scanned. On an approval round-trip the hosting
  layer replays the stored function_call item and its mcp_approval_request
  item as two separate assistant messages — so the check never fired and the
  approval request restored a duplicate of the call.

  Only one copy was matched to the function result. The orphaned copy went back
  to the service unanswered, which is exactly what the 400 reports.

  The fix collects existing call ids across all messages, and adds a restored
  call to that set so two approval requests for the same call cannot both expand.

• What is the impact of these changes?

  Not a breaking change; no public API or signature changes. Conversation history
  sent on an approval round-trip now contains each function_call exactly once,
  paired with its result.

  Verified with a full-stack ResponsesHostServer + SkillsProvider repro
  (load_skill approval, then run_skill_script approval). Outgoing history on
  the final turn, before and after:

  before                                after
  ------------------------------------  ------------------------------------
  user      [text]                      user      [text]
  assistant [function_call   call_1]    assistant [function_call   call_1]
  assistant [function_call   call_1]    tool      [function_result call_1]
  tool      [function_result call_1]    assistant [function_call   call_2]
  assistant [function_call   call_2]    tool      [function_result call_2]
  assistant [function_call   call_2]
  tool      [function_result call_2]
  

  Regression test added in
  python/packages/core/tests/core/test_function_invocation_logic.py; it fails on
  main with ['call_1', 'call_1'] == ['call_1']. Core suites and all 192
  agent-framework-foundry-hosting tests pass.

• What do you want reviewers to focus on?

  Two things I could not close out locally, both worth a second opinion:

  1. I could not reproduce the reported Inspector hang — against a mock chat
     client the registered script_runner was invoked on both the pre-fix and
     post-fix paths. This change fixes the duplication that produces the 400;
     whether the hang is entirely downstream of it is unconfirmed without the
     live Foundry API.
  2. The duplication also affects load_skill's call, so on a strict reading the
     reported flow should have failed one turn earlier than the issue describes.
     That may mean the service tolerates some duplicate shapes, or that a second
     factor is involved.

Related Issue

Fixes #7267

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow automatically keeps the label and title prefix in sync.