#10097: fix: add empty thinking blocks to tool call messages when thinking is…

… enabled When switching from a model with thinking disabled to a model with thinking enabled, API requests would fail with: "400 thinking is enabled but reasoning_content is missing in assistant tool call message" This happens because historical assistant messages with tool calls were generated without thinking blocks, but the API requires all assistant tool call messages to have reasoning_content when thinking is enabled. This fix: 1. Adds `hasHistoryToolCallWithoutThinking()` to detect incompatible history 2. Adds `addEmptyThinkingToToolCallMessages()` to add empty thinking blocks 3. Calls these in `sanitizeSessionHistory()` when thinking is enabled Fixes #XXXX <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR hardens session history sanitization for “thinking-enabled” models by detecting assistant messages that contain `toolCall` blocks but lack any `thinking` block, and then prepending an empty thinking block to those messages during `sanitizeSessionHistory()`. The change is implemented in `src/agents/pi-embedded-helpers/openai.ts` (new detection + rewrite helpers) and is wired into the embedded runner’s history sanitization (`src/agents/pi-embedded-runner/google.ts`), with callsites passing `thinkingEnabled` from the run/compaction flows. A new vitest suite covers the helper functions’ behavior. <h3>Confidence Score: 3/5</h3> - This PR is directionally safe but needs a correctness gate before merging. - The core helper logic is small and covered by unit tests, but the sanitizer applies an OpenAI-specific transcript mutation to all model providers when `thinkingEnabled` is true, which can break non-OpenAI payload schemas and turn validation. - src/agents/pi-embedded-runner/google.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->