#19105: fix(slack): suppress system events for bot's own reactions

When the bot reacts to a message (e.g. acknowledgment), it triggers a 'reaction_added' event, causing a redundant System Event in the session history. Fix: Filter out reaction events where the actor is the bot itself. Recreated from #18714 with only the relevant file. <!-- greptile_comment --> <h3>Greptile Summary</h3> Filters out Slack reaction events (`reaction_added` / `reaction_removed`) where the actor is the bot itself, preventing redundant system events from being enqueued when the bot reacts to messages (e.g. acknowledgment emojis). The guard `event.user === ctx.botUserId` is added at the top of `handleReactionEvent`, before any API calls or side effects, which is the correct placement. Import ordering was also adjusted to place type imports before value imports. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge — it adds a simple, well-placed guard clause with no risk of side effects. - The change is minimal and targeted: a single early-return guard comparing `event.user` against the known `ctx.botUserId`. The `SlackReactionEvent` type defines `user` as `string | undefined`, and `ctx.botUserId` is a `string`, so the `===` comparison handles the `undefined` case correctly (no match). The guard is placed before any API calls or `enqueueSystemEvent`, avoiding unnecessary work. The import reordering is cosmetic only. No tests exist for this file, but the logic is straightforward enough that the risk is negligible. - No files require special attention _{Last reviewed commit: ef94f4d} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->