feat(registry): add per-tool timeout enforcement

[chinadbo]

Summary

• Add timeout field to ToolEntry and registry.register() — tools can now declare a wall-clock timeout in seconds
• registry.dispatch() runs sync handlers in a thread when a timeout is set, returning a clear JSON error if execution exceeds the limit
• 9 tests covering ToolEntry.timeout, register() pass-through, and dispatch timeout enforcement (fast completion, timeout exceeded, no-timeout default, error message content)

Problem

Only environment-layer commands and MCP tool calls had timeout guards. Regular tool dispatch had no wall-clock limit — a misbehaving or slow handler could block the agent loop indefinitely with no feedback.

Test plan

• pytest tests/run_agent/test_tool_timeout_enforcement.py -v -o addopts="" — 9/9 passed
• ToolEntry.timeout defaults to None, stores custom values
• register() passes timeout to ToolEntry
• Fast tool completes within timeout and returns result
• Slow tool exceeds timeout and returns JSON error
• Tool with timeout=None runs without a timeout guard
• Timeout error includes tool name and timeout value

[teknium1]

Thanks for addressing a real gap: current ToolRegistry.dispatch() directly invokes synchronous handlers at tools/registry.py:584-588.

Problems

• tools/registry.py:342 submits a bare worker. Current tools/thread_context.py:4-18 documents that this loses approval/session ContextVars and thread-local approval/sudo callbacks; existing thread fan-out sites wrap targets with propagate_context_to_thread().
• The timeout does not stop execution: the PR documents that the worker continues at tools/registry.py:323-328 and returns via shutdown(wait=False) at line 351. The synthetic sleep tests verify prompt return, not cancellation or side-effect cleanup.
• The PR adds no timeout= registration for a bundled tool. A current-tree AST scan found zero existing registrations using this API, so there is no production handler whose behavior changes.

Suggested changes

• Start from a concrete handler and test its real dispatch path.
• Preserve thread context and use a handler/resource-specific cancellation mechanism, or narrow the contract to an explicitly non-cancelling caller deadline.
• Reconcile the conflicting registry changes with current dynamic_schema_overrides, override-policy, generation, and error-sanitization behavior.

Automated hermes-sweeper review.

[teknium1]

This bare worker drops the current ContextVars and thread-local approval/sudo callbacks. tools/thread_context.py:4-18 documents the security consequence, and current worker call sites use propagate_context_to_thread(...); wrap _target before submitting it.

[teknium1]

wait=False only lets dispatch return; it leaves the timed-out handler running and able to perform later side effects. Please use a handler-specific cancellation/cleanup mechanism or narrow the feature contract so it does not claim execution is terminated.