#6509: fix(slack): pass threadId param in read action

## Summary The Slack extension's `handleAction` for `action='read'` was not passing the `threadId` parameter to `handleSlackAction`, causing thread reads to return main channel messages instead of thread replies. ## Problem When calling: ``` message action=read channel=slack channelId=CCNNNLEMN threadId=1769960252.206929 limit=3 ``` The `threadId` parameter was being dropped in `extensions/slack/src/channel.ts`, so the Slack API's `conversations.history` was called instead of `conversations.replies`, returning main channel messages rather than thread replies. ## Fix Added the missing `threadId: readStringParam(params, "threadId")` to the read action handler in the Slack extension plugin. ## Testing Tested locally - thread reads now correctly return thread replies with `thread_ts` matching the requested thread. Fixes #6363 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR fixes Slack `read` action handling by forwarding the `threadId` parameter from `extensions/slack/src/channel.ts` into `handleSlackAction` for `readMessages`, allowing the Slack runtime to fetch thread replies (via `conversations.replies`) instead of falling back to channel history when a thread read is requested. The change is localized to the Slack channel plugin’s action dispatcher and aligns the `read` path with other actions (e.g., `send` already forwards thread context via `threadTs`). <h3>Confidence Score: 5/5</h3> - This PR is safe to merge; it’s a minimal, targeted bug fix with low regression risk. - The change only adds a missing parameter pass-through in the Slack action dispatcher and does not alter control flow or shared logic; it aligns with existing parameter forwarding patterns used elsewhere in the same file. - No files require special attention <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->