Foundry chat clients leak aiohttp sessions across agent runs

> Please provide us with the following information:
> ---------------------------------------------------------------

### This issue is for a: (mark with an `x`)
```
- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)
```

### Minimal steps to reproduce
1. Configure an agent app with `AZURE_FUNCTIONS_AGENTS_PROVIDER=foundry`, `FOUNDRY_PROJECT_ENDPOINT`, and a Foundry model.
2. Run the app with `func start`.
3. Execute one or more agent turns. The `samples/per-agent-workflows` scenario also reproduces this after primary and Workflow Sub Agent calls complete successfully.
4. Stop the Functions host.

The current ownership path is:

- `runner._build_agent_session_history()` calls `ClientManager.build_chat_client_with_target()` for every primary run.
- `runner._build_delegated_agent()` does the same for every delegated/Workflow Sub Agent run.
- `MAFClientManager._build_foundry()` constructs a fresh `FoundryChatClient` with a fresh async credential.
- Agent Framework 1.3.0 internally constructs and stores an async `AIProjectClient`; that client exposes async `close()` and owns an `aiohttp.ClientSession`.
- The runtime does not retain or close the generated chat/project clients. `MAFClientManager` inherits the no-op `ClientManager.close()` implementation.
- `shutdown_client_manager()` exists but has no production caller, and would not close these untracked resources even if called.

### Any log messages given by the failure
```
Unclosed client session
client_session:
```

The agent/workflow result itself can still complete successfully before this warning is emitted.

### Expected/desired behavior
Foundry HTTP transports and async credentials should have an explicit owner and be closed deterministically. No `Unclosed client session` warning should appear after successful, failed, timed-out, canceled, or streaming agent execution, including delegated and Workflow Sub Agent calls.

Suggested acceptance criteria:

- Define whether provider resources are per-run or process-wide and track them accordingly.
- Close Foundry `AIProjectClient`/transport and owned async credentials exactly once.
- Cover non-streaming success/error/timeout/cancellation and streaming completion/disconnect paths.
- Ensure any process-wide shutdown API is actually wired into the runtime lifecycle.
- Add tests that fail when a generated provider resource is not closed.

### OS and Version?
Windows_NT, Azure Functions Core Tools 4.10.0, Functions runtime 4.1048.200.26180.

### Versions
- Python 3.13.15
- `agent-framework-foundry` 1.3.0
- `azure-ai-projects` 2.3.0
- `aiohttp` 3.14.3

### Mention any other details that might be useful
This is not specific to Dynamic Workflow drain mode. Workflows with Sub Agents make the leak more visible because both coordinator and specialist execution construct fresh Foundry clients. Repeated turns in a long-lived worker may accumulate transports before process shutdown, so this should not be treated only as cosmetic shutdown logging.

> ---------------------------------------------------------------
> Thanks! We'll be in touch soon.

Start by tracing runner._build_agent_session_history() and runner._build_delegated_agent() into MAFClientManager._build_foundry(), then inspect the inherited ClientManager.close() and shutdown_client_manager() lifecycle. Add tests covering the listed success, error, timeout, cancellation, and streaming paths; done means generated Foundry resources and credentials are owned, closed exactly once, and no unclosed-session warning remains.

Written by the indexing model from the issue text.