tool_use ids were found without tool_result blocks immediately after

[KeironLowePatchWorks]

We occasionally get an error tool_use ids were found without tool_result blocks immediately after, the docs list the cause and fix here. This is an agent, which has structured output and 16 tools.

FYI, the below was found by Claude, but posting in case it might be useful.

Root cause: unexecuted tool calls included in stored response when maxSteps is exceeded

When processResponse() determines $shouldContinue = false due to hitting the maxSteps limit mid-turn, it skips executeToolCalls() — so $toolResults stays empty for that final turn. However, the StructuredTextResponse is still built by flatmapping tool calls and results across all steps, meaning the unexecuted tool calls from the final turn are included in toolCalls with no corresponding entries in toolResults.

Since there is no output_structured_data block in the response (the model never got to return its final answer), extractStructuredOutput() returns [], so the stored content is "[]" — the user receives a silent empty response with no indication the step limit was reached.

This manifests as two sequential symptoms:

1. First: the user receives an empty [] response with no explanation
2. Next message: replaying the corrupt history to the API fails with "tool_use ids were found without tool_result blocks", because the AssistantMessage references a tool use ID that has no corresponding tool_result block — leaving the conversation permanently broken

Two fixes needed:

1. When maxSteps is exceeded with pending $realToolCalls, those unexecuted calls should be excluded from the final response's toolCalls collection. Ideally the limit should also be surfaced to the caller rather than silently swallowed.
2. DatabaseConversationStore::getLatestConversationMessages() should defensively filter out tool calls with no matching result before replaying history, to prevent permanently broken conversations from this corrupt state.