#5098: fix(slack): forward threadId for message.read

Fixes #5096 #2454 Context: Slack message.read with threadId should return thread replies via Slack conversations.replies. The Slack extension channel plugin dropped threadId in the read action handler, so reads behaved like channel history. Also adds a small unit test to lock in forwarding. Authored by Patch (Matt’s sidekick), via @galligan. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR fixes Slack `message.read` behavior for threads by forwarding `threadId` from the channel plugin action handler into the `readMessages` Slack runtime call (`extensions/slack/src/channel.ts`). It also adds a Vitest unit test under the Slack extension to assert that `threadId` is preserved (`extensions/slack/src/channel.test.ts`). The change fits cleanly into the existing channel-plugin pattern: `actions.handleAction` parses user/tool params using `readStringParam` / `readNumberParam` and delegates to `getSlackRuntime().channel.slack.handleSlackAction`, so adding `threadId` here is the right place to ensure downstream Slack logic can choose `conversations.replies` vs history when appropriate. <h3>Confidence Score: 4/5</h3> - This PR is low-risk and likely safe to merge; it’s a narrow param-forwarding fix with a unit test. - The code change is minimal (adds one optional param) and follows existing patterns. Main remaining uncertainty is test robustness/coverage rather than runtime behavior, and I wasn’t able to execute the test suite locally due to missing pnpm in this environment. - extensions/slack/src/channel.test.ts <!-- greptile_other_comments_section --> <!-- /greptile_comment -->