#9963: fix(slack): extract text from forwarded message attachments

## Problem When a Slack message is forwarded (shared from another channel), the content is stored in the `attachments` array rather than the main `text` field. This caused forwarded messages to appear empty to the agent - only showing the wrapper text like "fyi in case you need to change anything" without the actual forwarded content. ## Solution - Added `extractAttachmentText()` helper function to parse `message.attachments` - Handles `is_msg_unfurl` and `is_share` attachment types (forwarded messages) - Prefixes extracted text with `[Forwarded from Author]` for context - Falls back to `message_blocks` parsing when `text` field is empty - Combines main text with attachment text in `rawBody` ## Testing 1. Forward a message from one Slack channel to another where the bot is monitoring 2. Verify the bot receives both the wrapper text AND the forwarded content 3. Verify the forwarded content is prefixed with author attribution ## Before ``` fyi in case you need to change anything on the Super Bowl ads. ``` ## After ``` fyi in case you need to change anything on the Super Bowl ads. [Forwarded from Rebecca] howdy! last notes on the super bowl: -wings are a different price than usual... ``` <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates Slack inbound message preparation to include content from forwarded/shared messages stored in `message.attachments`. It introduces a `SlackAttachment` type (`src/slack/types.ts`) and an `extractAttachmentText()` helper (`src/slack/monitor/message-handler/prepare.ts`) that attempts to pull forwarded text from `attachment.text` and fall back to parsing `attachment.message_blocks`, then combines attachment text with the main `message.text` when constructing `RawBody`. Main concern: the `message_blocks` fallback logic/type does not appear to match Slack’s common payload shape, so forwarded messages that omit `attachment.text` can still end up empty, and the author prefixing currently repeats for each extracted text segment. <h3>Confidence Score: 3/5</h3> - This PR is moderately safe to merge, but has a functional gap in the forwarded-message fallback parsing. - Core change is localized and low-risk, but the new `message_blocks` schema/parsing likely doesn’t match real Slack forwarded attachment payloads, which can cause the PR’s main fix to fail for a common case (attachments without `text`). - src/slack/monitor/message-handler/prepare.ts; src/slack/types.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->