Return error response for unknown tool calls instead of silently skipping

[dgageot]

Two improvements:

1. Bug fix - unknown tool calls get an error response instead of being silently dropped. On main, when the model calls a tool that doesn't exist (the else branch), the call is skipped with no tool response message added to the session. This leaves a tool_call without a matching tool_response, which violates the LLM API contract and can cause errors or confused model behavior on the next turn. This commonly happens after a handoff: agent A sees tool calls from agent B in the conversation history and tries to use them. Now it gets a clear error telling it the tool isn't available.

2. Simpler structure - one availability check instead of two separate rejection paths. On main, the availability logic has three branches with two different rejection paths.

The new code separates this into two sequential steps: check agentToolMap once (reject if missing), then pick the handler. This removes
the nested if, deduplicates the rejection logic, and makes the flow read top-down: is it available ‚Üí how do we run it ‚Üí run it.

Assisted-By: cagent

[docker-agent]

Review Summary

No issues found in the changed code. The PR correctly implements error responses for unknown tool calls and simplifies the tool resolution logic.

Changes Verified:

1. Bug fix: Unknown tool calls now receive proper error responses instead of being silently skipped, which fixes the LLM API contract violation
2. Code simplification: The new two-step flow (availability check → handler selection) is clearer than the previous nested structure
3. Test coverage: The test was appropriately updated to verify the new error response behavior

The refactoring maintains the same functionality while making the code more maintainable and fixing a real bug where tool calls without matching responses could confuse the model.