This PR fixes three regressions/issues that surfaced around Feishu delivery, MiniMax tool calling, and scheduler delivery reliability.

On the Feishu side, users could no longer receive files from the agent. The recent Feishu reaction-protocol work intentionally discouraged send_message for normal visible replies so that the adapter could parse reaction directives from the final assistant text. The problem was that the runtime-level guard blocked send_message unconditionally for Feishu turns, which also blocked the only attachment-delivery path. In practice this meant the agent could still prepare files locally, but it could no longer send them back to users in Feishu chats.

This change narrows that guard instead of removing it. Feishu and Lark turns still reject text-only send_message calls so normal replies continue to flow through the adapter's reaction/text parsing path, but send_message calls that include attachment_path are now allowed. The Feishu system prompt and tool metadata were updated to make this distinction explicit: use direct final assistant text for normal replies and reactions, and use send_message only when an attachment must actually be delivered.

The second issue was MiniMax leaking raw tool-use text into the user-visible reply stream. Some MiniMax responses were arriving in a partially non-standard OpenAI-compatible shape, including reasoning under reasoning_details and tool invocations wrapped as raw text such as [tool_use: bash(...)] inside MiniMax-specific wrapper tags. When that happened, the provider adapter treated the payload as plain visible text instead of reconstructing proper tool-call blocks, so users could see raw tool protocol text in channels.

This PR hardens the OpenAI-compatible translation layer for MiniMax by accepting reasoning_details as an alias for reasoning content and by recognizing MiniMax wrapper tags around raw [tool_use: ...] text. When the response does not already include structured tool_calls, the adapter now strips the wrapper markup, parses the raw tool-use text back into ToolUse blocks, and prevents that protocol text from being shown to users as normal assistant output.

The third issue addressed here is #291, where scheduled tasks frequently ran into platform delivery rate limits. Previously the scheduler would call deliver_and_store_bot_message once for success or failure notifications and then proceed, which meant transient 429 or rate-limit responses were effectively treated as final delivery outcomes. Depending on the timing, a scheduled task could produce a valid response but fail to notify the chat because the first delivery attempt happened during a brief burst window.

To make this path more resilient, the scheduler now retries delivery with bounded exponential backoff when the delivery error looks like a rate-limit condition. The retry classifier covers common English and Chinese limit signals such as 429, rate limit, too many requests, 频控, 限流, and 请求过于频繁. If delivery still fails after the bounded retries, the task run is recorded as failed with delivery context instead of being silently treated as a clean success.

Validation for this PR includes targeted Rust tests covering each of the new behaviors:

• cargo test test_feishu_send_message_allows_attachment_tool_calls -- --nocapture
• cargo test test_feishu_reaction_guard_allows_attachment_send -- --nocapture
• cargo test test_translate_oai_response_turns_raw_tool_text_into_tool_use -- --nocapture
• cargo test test_process_openai_stream_event_collects_reasoning_details_alias -- --nocapture
• cargo test test_is_retryable_delivery_rate_limit_recognizes_common_errors -- --nocapture
• cargo test --no-run

Closes #291.