fix(slack): surface retryable + Retry-After on send() rate-limit errors (#46762)

[srojk34]

Summary

• The Telegram adapter (PR Telegram sendRichMessage flood-control retry ignores server retry_after and drops final response #46762 / commit 404b06ac4) extracts retry_after from FloodWait errors and sets retryable=True so the base _send_with_retry() layer can honor the server-requested backoff.
• Slack's send() caught all exceptions and returned a bare SendResult(success=False) — never setting retryable=True or extracting the Retry-After header. When Slack returned a 429 rate-limit error, the base layer saw retryable=False and did not retry, silently dropping remaining message chunks.
• Same bug class as the accepted P2 Discord issue ([Bug]: hermes send to Discord drops remaining chunks on a 429 — no retry in the standalone send path (Telegram has one) #44468 / PR fix(discord): retry 429s in the standalone send path, honoring retry_after #44488).

Repro scenario

1. Bot sends a multi-chunk response to a busy Slack workspace
2. Slack returns 429 ratelimited on a middle chunk with Retry-After: 30
3. send() catches the exception → SendResult(success=False, retryable=False) ← no retry
4. Base _send_with_retry() sees retryable=False, "ratelimited" not in _RETRYABLE_ERROR_PATTERNS → gives up
5. Remaining chunks silently dropped ❌

Fix

Reuse the existing _is_retryable_upload_error() helper (which already detects 429, 500+, and connection errors for the upload path) to set retryable=True on the send() path. Extract the Retry-After header from the SlackApiError response when present.

Test plan

• test_429_returns_retryable_with_retry_after — 429 + Retry-After: 30 → retryable=True, retry_after=30.0
• test_429_without_retry_after_header — 429 without header → retryable=True, retry_after=None
• test_500_is_retryable_no_retry_after — 500 → retryable=True
• test_403_is_not_retryable — 403 → retryable=False (unchanged)
• test_connection_error_is_retryable — ConnectionError → retryable=True
• All 209 existing Slack tests pass (zero regression)

$ pytest tests/gateway/test_slack_send_retry.py tests/gateway/test_slack.py -q
214 passed in 3.30s

[teknium1]

Thanks for tracing the missing Slack rate-limit classification; current main still returns a bare failed SendResult from SlackAdapter.send() at plugins/platforms/slack/adapter.py:1435-1437.

Problems

• The new retryable=True path would cause BasePlatformAdapter._send_with_retry() to call send() again with the complete original content (gateway/platforms/base.py:4148). SlackAdapter.send() posts split responses sequentially (plugins/platforms/slack/adapter.py:1396-1410), so a 429 on a middle chunk would replay already delivered prefix chunks and duplicate them.

Suggested changes

• Retry only the failed Slack chunk, honoring Retry-After, instead of returning a retryable whole-message failure to the base retry wrapper.
• Add a multi-chunk regression where chunk one succeeds and chunk two receives 429; assert chunk one is emitted once.

Automated hermes-sweeper review.

[teknium1]

Marking a failure from this whole-message send() retryable makes _send_with_retry() invoke send() again with the full original content. Since send() posts chunks sequentially, a 429 after earlier chunks succeeded will replay those prefixes and duplicate them. Retry the failed chunk locally (and honor its Retry-After) rather than escalating this result to the whole-message retry layer.

[teknium1]

Merged via #69479 — your commit was cherry-picked/reapplied onto current main with your authorship preserved in git history: your retryable + Retry-After surfacing was cherry-picked directly.

Thanks for the contribution!