What does this PR do?

The internal tool_name key on role=tool messages — stored in the
messages.tool_name SQLite column for FTS indexing — is not part of the
OpenAI Chat Completions schema. Strict OpenAI-compatible providers, notably
Moonshot AI (Kimi), reject any request containing it with HTTP 400:

Error from provider: Extra inputs are not permitted,
field: 'messages[N].tool_name', value: 'execute_code'

This PR adds tool_name to the sanitize block in
ChatCompletionsTransport.convert_messages, alongside the existing
Codex Responses API fields (codex_reasoning_items, codex_message_items),
so it is popped before the request is sent.

The strip is unconditional (matches the existing Codex-strip pattern):
tool_name is never part of any documented OpenAI Chat Completions payload,
so removing it before send is safe for every provider while fixing the
strict ones. Permissive backends (MiniMax, OpenRouter on most routes) were
ignoring the extra field and masking the bug.

Related Issue

Fixes #

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• agent/transports/chat_completions.py — extend the needs_sanitize
  detection and the per-message pop step in convert_messages to cover
  the tool_name key.
• tests/agent/transports/test_chat_completions.py — add
  test_convert_messages_strips_tool_name covering both the strip on the
  returned list and the deepcopy-on-demand contract (original input
  untouched).

How to Test

Reproducer:

hermes chat --model kimi-k2.6
> list the top 5 Hacker News stories

Before the fix:

1. assistant emits tool_call(execute_code)
2. the tool result message is persisted with tool_name='execute_code'
3. the next-turn payload includes messages[N].tool_name
4. Kimi rejects with HTTP 400 (Extra inputs are not permitted, field: 'messages[N].tool_name')

After the fix:

1. Same flow, but convert_messages strips tool_name before send.
2. Request succeeds, multi-turn tool-using conversations complete normally
   on kimi-k2.6 (verified end-to-end on macOS 15.x, Hermes Agent v0.14.0).

Automated:

pytest tests/agent/transports/test_chat_completions.py -q

The new test (test_convert_messages_strips_tool_name) asserts:

• tool_name is removed from the returned message
• tool_call_id and content are preserved
• the original input list is unmodified (deepcopy-on-demand contract)

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(chat_completions): …)
• I searched for existing PRs/issues — none target this specific field
• My PR contains only changes related to this fix
• I've run pytest tests/agent/transports/test_chat_completions.py -q and all tests pass
• I've added a test for the fix
• I've tested on my platform: macOS 15.x (Apple Silicon)

Documentation & Housekeeping

• N/A — no public docs reference the internal tool_name field
• N/A — no config keys added/changed
• N/A — no architectural or workflow changes
• Cross-platform: the change is a pure dictionary pop, no platform-specific behavior
• N/A — no tool descriptions/schemas changed