Fix reasoning_content error in tool calls for kimi-k2.5 and other thi…

[jdhxyy]

…nking models

📝 Description

🗣️ Type of Change

• 🐞 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 📖 Documentation update
• ⚡ Code refactoring (no functional changes, no api changes)

🤖 AI Code Generation

• 🤖 Fully AI-generated (100% AI, 0% Human)
• 🛠️ Mostly AI-generated (AI draft, Human verified/modified)
• 👨‍💻 Mostly Human-written (Human lead, AI assisted or none)

🔗 Related Issue

Fixes #588

📚 Technical Context (Skip for Docs)

• Reference URL:
• Reasoning:

🧪 Test Environment

• Hardware:
• OS:
• Model/Provider:
• Channels:

📸 Evidence (Optional)

Click to view Logs/Screenshots

☑️ Checklist

• My code/docs follow the style of this project.
• I have performed a self-review of my own changes.
• I have updated the documentation accordingly.

[nikolasdehor]

Good targeted fix for #588. The field naming (ReasoningContent) is consistent with the existing Message struct. Two observations: (1) Incomplete fix? This PR preserves reasoning_content in the outbound serialization (stripSystemParts), but I don't see where response.ReasoningContent is copied into the assistant Message during tool loop execution. Without that, the ReasoningContent field will be empty for assistant messages created in toolloop.go. PR #889 addresses this in toolloop.go:109 — you may need to add that piece here too, or coordinate with that PR. (2) Unrelated .gitignore change: The __debug_bin patterns are fine but would be cleaner as a separate commit. (3) Test: Consider adding a test for stripSystemParts that verifies ReasoningContent is preserved. The core approach is correct — please verify the tool loop path is also covered.