[Feature]: Support dynamic tool injection during ChatAgent.run() execution

Description

Problem

When a tool function executed during ChatAgent.run() dynamically loads new tools (e.g., by discovering and registering additional capabilities from an MCP server), those new tools are not visible to the LLM within the same run() invocation. This is because run() captures the tool list at the start and uses that fixed list for all subsequent LLM calls within the run loop.

This forces callers to implement a workaround:

1. Detect that tools were loaded mid-run (via a flag set by the tool function)
2. Discard the current run() response (the LLM couldn't use the new tools, so its response is a throwaway)
3. Re-invoke run() with the updated tool list

This wastes one full LLM round-trip per dynamic tool load (~2-5K tokens, 2-10 seconds latency).

Expected Behavior

A tool function executed during run() should be able to make new tools visible to the LLM on its next turn within the same run() call — without requiring the caller to discard the response and re-invoke run().

Possible approaches (in order of our preference):

1. Live tool list reference — Instead of copying/snapshotting the tools list at the start of run(), reference it by reference so that mutations (appends) made by tool functions are visible on the next LLM call within the run loop. This is the simplest change and matches how most callers expect mutable lists to behave.
2. Tool reload callback — Provide a hook that run() calls before each LLM request to refresh the tool list. For example: ChatAgent(tool_provider=lambda: current_tools).
3. Tool injection API — Expose a method like run_context.inject_tools(new_tools) that tool functions can call to update the active tool set for the current run().

Impact

Eliminating the re-run would save ~2-5K tokens and 2-10 seconds of latency per dynamic tool load. For agents that load tools on every new conversation, this is a consistent per-session cost.

Code Sample

Language/SDK

Both

Start at ChatAgent.run(), where the issue says the tool list is captured, and trace how that list is supplied to each later LLM call. The issue names no file or test; done means a tool executed during one run can register another tool and the next LLM turn can use it without re-invoking run().