fix: repair orphaned tool_calls in context for DeepSeek compatibility

[efecnc]

Summary

• Fixes 400 invalid_request_error from DeepSeek when a previous reasoning loop was cancelled mid-tool-execution, leaving orphaned assistant messages (with tool_calls) in SQLite memory without corresponding tool response messages
• Adds repair_tool_call_context() which injects placeholder tool responses for any missing tool_call_id before sending context to the provider
• Defensive fix that works for all OpenAI-compatible providers, not just DeepSeek

Root Cause

When the reasoning loop is cancelled (via /cancel, timeout, or signal):

1. The assistant message with tool_calls has already been persisted to memory (agent/mod.rs:1516)
2. The early-return on cancellation (lines 1540, 1615, 1646, 1704) skips saving the corresponding tool response messages
3. On the next turn, get_context_since_reflection() loads this broken sequence
4. DeepSeek strictly validates that every tool_call_id has a matching tool response — rejects with 400

Test plan

• Verify cargo check passes (confirmed locally — no new warnings)
• Trigger cancellation mid-tool-execution, then send a new message — should no longer produce 400 errors on DeepSeek
• Verify other providers (OpenAI, Gemini, Anthropic) still work correctly with the repair in place

[gemini-code-assist]

Code Review

This pull request introduces a repair_tool_call_context function to ensure that assistant messages with tool calls are always followed by corresponding tool responses, preventing errors with strict LLM providers like DeepSeek. Feedback suggests refining the insertion logic to maintain the correct sequence of tool responses and improve loop efficiency by appending missing responses at the end of the tool block.

[gemini-code-assist]

Inserting missing tool responses at i + 1 can result in an incorrect sequence if some tool responses already exist in the context. Most LLM providers (including DeepSeek) expect tool responses to appear in the same order as the tool_calls array in the assistant message. Additionally, setting i = j after the insertions causes the loop to re-scan the tool messages (both existing and newly inserted), which is slightly inefficient. Consider appending the missing responses to the end of the tool block (at index j) and updating i to skip the entire block.

        for id in missing {
            context.insert(
                j,
                crate::utils::ChatMessage::tool("[Cancelled — tool execution interrupted]", &id),
            );
            j += 1;
        }

        i = j;

[efecnc]

✅ Ready to merge. The ordering fix (d7aec5a) correctly appends placeholder tool responses at the end of the tool block instead of at i+1. No further changes needed.