.NET: Isolate Foundry toolbox response cache - #8848

Motivation & Context

Foundry toolbox clients opened while serving a response were retained by the singleton toolbox service under the toolbox name. That lifetime allowed later responses to reuse client and tool state created under a different request context.

This change aligns request-opened toolbox ownership with the response lifetime while preserving safe reuse for clients opened during container startup.

Description & Review Guide

• What are the major changes? Add an opaque response cache scope, keep lazy, deferred, and consent retry results inside that scope, and dispose scoped MCP and HTTP clients when the response completes or exits early. Add service-level and handler-level regression coverage for concurrent responses, reuse, isolation, streaming context continuity, and cleanup.
• What is the impact of these changes? Startup-opened toolboxes remain shared. Toolboxes opened during request handling are reused only within that response and are independently opened for other responses.
• What do you want reviewers to focus on? Please review the response-scope lifecycle in AgentFrameworkResponseHandler, the separation between startup and request caches in FoundryToolboxService, and cleanup across normal and exceptional exits.

Related Issue

N/A. This change is tracked in a restricted incident record, so no GitHub issue is created.

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 keeps the label and the title prefix in sync automatically.