refactor: share ReAct tool invocation lifecycle boundary

[rogercloud]

Control tool calls currently bypass ReAct's ordinary invocation wrapper. A failed or cancelled control send can therefore exit without a terminal ledger record, and outbound messages do not carry their originating tool-call information.

This change routes control calls through the existing shared invocation boundary for context preparation, start recording, and exceptional cleanup. It preserves control-specific result handling, waiting/final-answer behavior, and ordinary-tool tracing and metering. Message metadata carries minimal call attribution, including ordered sources for aggregated questions. Execution context is enriched on copies so pending-call identity and existing checkpoint contents remain intact.

This is the stage A prerequisite for #2145. It does not implement durable attempt identity, message idempotency, or crash recovery; those still require integration in 3.2. The included design document and diagram describe the bounded scope.

Validation:

• 531 tests passed across ReAct, segmentation/concurrency, clarification, runtime, DAG, and Auto, including 9 new regression cases.
• Ruff formatting and lint passed for the changed Python files.
• Targeted mypy passed for ReAct with --follow-imports=silent.

[gemini-code-assist]

Code Review

This pull request unifies the tool call lifecycle boundaries in the ReAct agent pattern by routing both ordinary and control tools through a shared execution wrapper (_execute_tool_safely). This ensures consistent preparation and lifecycle tracking while preserving tool-specific behaviors, such as tracing and metering for ordinary tools. Comprehensive regression tests have been added to validate these changes. The feedback suggests catching general Exceptions for control tools in _execute_tool_safely to record the actual error message in the ledger instead of falling back to a generic abort message.

[qinxuye]

LGTM