fix(discord): retry 429s in the standalone send path, honoring retry_after

[AIalliAI]

Summary

Fixes #44468 — hermes send --to discord:... dropped all remaining chunks of a multi-chunk message when one chunk hit a 429, because the standalone REST path (plugins/platforms/discord/adapter.py::_standalone_send) converted any 429 straight into an error dict with no retry, and the Discord chunk loop in tools/send_message_tool.py returns on the first error.

This adds _standalone_post_with_retry to the Discord plugin and applies it to the standalone text-message POST and both forum thread-creation POSTs:

• Bounded retry: 3 attempts (same as the Telegram helper _send_telegram_message_with_retry).
• Honors retry_after: parsed from the 429 JSON body first (Discord reports sub-second precision there, e.g. the retry_after: 0.3 from the issue), falling back to the Retry-After / X-RateLimit-Reset-After headers, then to exponential backoff (1s, 2s) when neither parses.
• Capped: a retry_after above 10s (long/global rate limit) fails fast instead of stalling the blocking CLI/tool call.
• No behavior change otherwise: non-429 errors keep single-attempt behavior, and error dict formats are byte-identical, so the chunk loop and other consumers see the same shapes.
• The forum multipart body is rebuilt per attempt via a form factory — an aiohttp FormData cannot be sent twice.

With retry inside _standalone_send, the chunk loop in send_message_tool.py needs no change: a transient 429 on chunk N now retries and succeeds, and the remaining chunks proceed — parity with the Telegram path, which retries inside _send_telegram. (The per-media upload loop is left as-is: its failures are already non-fatal warnings that don't drop subsequent sends, and wrapping it would change its streaming-from-disk memory profile.)

Tests

New TestSendDiscord429Retry in tests/tools/test_send_message_tool.py:

• 429 then success → retried after exactly retry_after (0.3s), send succeeds, 2 POSTs
• persistent 429 → gives up after 3 attempts, surfaces the 429 error dict
• retry_after: 3600 → fails fast, no sleep, 1 POST
• 403 → not retried (old behavior preserved)
• unparseable 429 body → exponential backoff fallback (1s)

tests/tools/test_send_message_tool.py: 138 passed (35 Discord-related, 5 new).

[liuhao1024]

Verified the Discord standalone 429 retry implementation — clean, well-structured.

What I checked:

• Bounded retry: _STANDALONE_RETRY_ATTEMPTS = 3 with proper attempt counting ✅
• retry_after extraction: JSON body first (sub-second precision), then Retry-After/X-RateLimit-Reset-After headers ✅
• Max retry_after cap (_STANDALONE_MAX_RETRY_AFTER = 10.0): long-lived/global rate limits give up immediately instead of stalling a blocking CLI call ✅
• Exponential backoff fallback (2 ** attempt) when no parseable retry_after — correct for opaque 429s ✅
• form_factory pattern: aiohttp FormData cannot be sent twice, so the factory rebuilds per attempt — correct ✅
• Non-429 errors pass through without retry (original single-attempt behavior preserved) ✅
• Forum thread creation (both media and no-media paths) + text message send all route through _standalone_post_with_retry ✅
• Media file payloads extracted to file_payloads list before the factory closure — avoids re-reading files on retry ✅

Test coverage (5 tests): 429→success, persistent 429 exhaustion, huge retry_after gives up, non-429 not retried, no retry_after → backoff. Covers the key paths.

Parity with the Telegram retry helper in tools/send_message_tool is noted in the comment — the approach is consistent.

[AIalliAI]

Requesting maintainer review — this is ready to land from my side. Standalone fork CI is pending first-run approval here; the rollup branch in #44061 carrying this session's batch is fully green on upstream CI (all test shards, typecheck, e2e).

[teknium1]

Thanks for the focused Discord delivery fix. The premise is present on current main: the standalone text POST returns immediately for every non-2xx status at plugins/platforms/discord/adapter.py:8053-8063, and the chunk loop stops on that error at tools/send_message_tool.py:893-906. The PR's bounded 429-only retry therefore addresses the failure without changing the chunk-loop contract.

The PR base is an ancestor of current main; the only subsequent change to either touched file is an unrelated slash-command description at plugins/platforms/discord/adapter.py:4085, so this appears mechanically salvageable. No blocking defects found in the reviewed diff.

Automated hermes-sweeper review.

[andrexibiza]

Discord Feature Parity & Alignment Campaign interlock: tracked by EPIC #79564. Original contributor lane; preservation and integration routing remain explicit in the campaign ledger.