fix(agent): rebuild api_messages after provider fallback to apply reasoning requirements

[bradhallett]

Problem

When Hermes falls back from one provider (e.g. GLM-5.1) to DeepSeek/Kimi via _try_activate_fallback(), the api_messages array is stale — it was built before the fallback with the original provider's settings. Since _copy_reasoning_content_for_api runs with the original provider's model, DeepSeek-required reasoning_content padding is not added to assistant messages.

This causes HTTP 400 from DeepSeek:

The reasoning_content in the thinking mode must be passed back to the API.

Root Cause

The message-building block sits outside the inner retry loop. After _try_activate_fallback() success, the continue loops back to the retry loop top — not the message builder — so stale api_messages is reused with the wrong provider's settings.

Fix

1. Extract the inline message-building block into _build_api_messages() — an instance method on AIAgent that returns (api_messages, total_chars, approx_tokens).
2. Replace the inline block with a single call to the new method.
3. Add a _build_api_messages() call at all 6 _try_activate_fallback() sites in the retry loop to ensure api_messages is rebuilt with the current provider's settings before continuing.

Testing

• 12 new regression tests in tests/run_agent/test_build_api_messages_fallback.py
• Covers: DeepSeek padding, GLM mode (no padding), fallback simulation (GLM→DeepSeek, DeepSeek→GLM), method contract, message immutability
• All 36 existing test_deepseek_reasoning_content_echo.py tests continue to pass

Related

• Fixes DeepSeek direct API 400 "reasoning_content must be passed back" on multi-turn tool calls #17212, [Bug]: DeepSeek reasoning models crash with HTTP 400 on multi-turn sessions — reasoning_content dropped during session reload #17825
• Relates to fix: preserve conversation context when provider fallback activates #13235 (same approach, stale PR with no reviews)