fix(slack): read thread context from message attachments and blocks

[xcompass]

Problem

When the bot is @mentioned mid-thread for the first time, _fetch_thread_context
fetches prior thread messages (conversations.replies) and prepends them as context —
but it reads only each message's plain text field:

msg_text = msg.get("text", "").strip()
if not msg_text:
    continue

Apps like Alertmanager, Grafana, PagerDuty, and CI bots post with an empty text
and the real content in legacy attachments or Block Kit blocks. Those messages
are dropped — so when such a message starts the thread (e.g. a firing alert), an agent
asked to investigate sees an empty thread and can only reply "What should I investigate?".

Observed on a real Alertmanager thread (details genericized):

sender	text	content
Alertmanager (bot)	""	attachments[0] → [FIRING:1] KubeJobFailed cluster-01 batch-job-123456
user	@bot investigate	—
bot	"What should I investigate? …"	—

_fetch_thread_parent_text has the same gap.

Fix

When text is empty, fall back to:

1. _extract_text_from_slack_blocks(msg["blocks"]) — already used for live incoming messages;
2. a new _extract_text_from_slack_attachments(msg["attachments"]) helper that pulls
   pretext/title/text/fields (plus nested blocks), using the fallback string only
   when an attachment has nothing structured.

Applied in both _fetch_thread_context and _fetch_thread_parent_text. No behavior change
for messages that already have text.

Tests

New TestThreadContextAppMessages covers attachment-only (Alertmanager-style), blocks-only,
and truly-empty messages. tests/gateway/test_slack.py passes (incl. existing thread-context
tests) and ruff check is clean.

[alt-glitch]

This was generated by AI during triage.

Competing/related cluster for Slack bot-alert thread context: #33493 targets the now-relocated gateway/platforms/slack.py (_fetch_thread_context only, attachments[].text/fallback); this PR targets the current plugins/platforms/slack/adapter.py and is a superset — it adds Block Kit + a richer attachment extractor (pretext/title/fields/nested blocks) and covers _fetch_thread_parent_text too. #52219 is a sibling on a different code path (inbound message-text extraction, not fetched thread context). Not a duplicate; linking for reviewer comparison.

[teknium1]

Thanks for covering the fetched-thread path and the related parent-text path.

Problems

• The Block Kit portion is incomplete: _extract_text_from_slack_blocks only processes rich_text blocks at plugins/platforms/slack/adapter.py:203-205, while the new fallback at plugins/platforms/slack/adapter.py:3833-3836 relies on it for every block payload. An empty-text standard section block is therefore still dropped. The added blocks test uses only rich_text at tests/gateway/test_slack.py:4255-4267.

Suggested changes

• Render standard text-bearing Block Kit block types in this fetched-context fallback (or use an existing suitable sanitized representation) and add a section-block regression test.
• Add a cold-cache _fetch_thread_parent_text attachment/block regression test; the current tests cover _fetch_thread_context only.

Automated hermes-sweeper review.

[teknium1]

_extract_text_from_slack_blocks currently renders only rich_text blocks (adapter.py:203-205). This leaves ordinary text-bearing section blocks empty here, so the message is still skipped. Please cover standard Block Kit text blocks as well and add a matching regression test.

[teknium1]

Merged via #69316 — your commit was cherry-picked onto current main with your authorship preserved in git history: your attachments+blocks thread-context fallback was cherry-picked directly.

Thanks for the contribution!

[xcompass]

Thanks!