`Create_agent` Should Support Bounded Forced Retry After Tool Invocation Validation Errors

The agent loop in create_agent does not enforce a tool call retry after receiving a ToolMessage with status='error' that indicates a tool invocation validation failure. The model node always binds tools without forcing a specific tool, so if the model responds with plain text on the next turn, the agent terminates and returns that text as the final answer.

1. Create an agent using create_agent with a tool that has required schema fields (e.g., a tool with required field 'subagent_type'). 2. Prompt the agent to call the tool but with missing required field, causing the model to emit a tool call with invalid args. 3. Observe that ToolNode returns a ToolMessage with status='error' and content indicating validation failure. 4. The next model response may be a plain text message with corrected JSON instead of a new tool call. 5. Since the response has no tool calls, the agent loop treats it as final answer and returns it to the user.

The content-based detection of validation errors (checking for 'ValidationError' or 'ToolInvocationError' in ToolMessage.content) is fragile and may break if the error message format changes. Forcing `tool_choice` may not be supported by all model providers; the fallback to a system instruction may not reliably force a tool call. In multi-tool or parallel tool call scenarios, identifying the exact failed tool and associating errors with the correct AIMessage can be error-prone. The state update logic assumes the ToolNode does not overwrite `retry_count`; if a custom ToolNode does, the counter may reset incorrectly. Rollback: revert to the original `call_model` and remove `retry_count` from state to restore previous behavior. For robustness, prefer using structured exception types rather than content matching.