fix(slack): forward reaction_added events to the message pipeline

[bpross]

Summary

Skills that present confirmation-style proposals — "react 👍 to proceed, 👎 to drop" — couldn't work end-to-end because the Slack adapter never registered a handler for reaction_added. Events arrived at slack_bolt, were logged as Unhandled request, and discarded before reaching the agent. Users had to fall back to retyping their intent, which defeats the reaction UX.

This change adds the missing handler and synthesizes the reaction into the existing message pipeline, so reactions become first-class confirmation responses without any per-skill plumbing.

What changes

A new @app.event(\"reaction_added\") registration that calls a new _handle_slack_reaction method. The handler:

• Uses the reactor's user_id as the synthesized message's user, so the existing _is_user_authorized gate still applies — non-allowlisted users' reactions are dropped exactly like their typed messages would be.
• Looks up the reacted-to message via conversations.replies to find its thread_ts, so the synthesized event lands in the right thread. Skills waiting on a clarify in that thread receive the reaction as the next user response.
• Translates common reactions to their unicode emoji in the text field (thumbsup → 👍, +1 → 👍, white_check_mark → ✅, thumbsdown → 👎, etc.). Skill bodies that match on the typed character also fire on the equivalent reaction without needing to know Slack short-names. Custom workspace emoji fall through as :name:.
• Drops self-reactions (the bot's own :eyes: lifecycle marker, or any reaction added by the bot user_id) so they can't feed back into the pipeline.
• Ignores file-targeted reactions — only item.type == \"message\" is forwarded.
• Preserves the reaction name and reacted-to ts in a _hermes_reaction key on the synthesized event for any downstream code that wants to know it was a reaction rather than a typed message.

The reactor's response goes through _handle_slack_message unchanged — dedup, auth, thread-context, and skill routing all reuse the existing paths.

Tests

New TestSlackReactionForwarding class with five cases:

• test_reaction_synthesizes_message_in_thread — 👍 reaction on an in-thread bot message produces a synthesized event with the right thread_ts, user, and text.
• test_self_reaction_dropped — bot's own :eyes: reaction is not forwarded.
• test_unknown_reaction_uses_colon_name — custom workspace emoji falls through as :name:.
• test_non_message_reaction_ignored — file reactions are dropped.
• test_top_level_message_threads_to_self — reaction on a top-level message threads to that message's ts.

Full slack test sweep run locally:

```
python -m pytest tests/gateway/test_slack_approval_buttons.py tests/gateway/test_slack.py tests/gateway/test_slack_mention.py tests/gateway/test_slack_channel_skills.py
```

280 passed, 0 regressions.

Why this is a fix, not a feature

The README and skill-authoring docs encourage skills like "react 👍 to confirm" as a natural UX. The current adapter silently breaks that contract. Users see WARNING slack_bolt.AsyncApp: Unhandled request ({'type': 'event_callback', 'event': {'type': 'reaction_added'}}) in logs but no clue why their confirmation flow doesn't fire.

Test plan

• Synthesized event preserves user, text, channel, thread_ts
• Self-reactions don't feedback-loop
• Unknown reactions fall through with the short-name
• File reactions don't crash or forward
• Top-level reactions thread to themselves
• No regressions in the existing slack test modules

[teknium1]

Thanks for identifying a real gap: current main still acknowledges reaction_added without forwarding it (plugins/platforms/slack/adapter.py:1117-1127). The submitted implementation needs a rework before it can be salvaged.

Problems

• The patch targets the deleted gateway/platforms/slack.py; Slack now runs from plugins/platforms/slack/adapter.py after migration commit 560010547.
• The proposed handler does not verify that the reacted-to message was sent by Hermes. It reads event.item but ignores event.item_user, so a reaction on an unrelated human message can enter _handle_slack_message. Feishu performs this target-sender verification before routing reactions (plugins/platforms/feishu/adapter.py:2901-2915).
• Default generated manifests omit both reaction_added and reactions:read (hermes_cli/slack_cli.py:66-90), while this PR changes no manifest code.

Suggested changes

• Port the work to plugins/platforms/slack/adapter.py, verify the target belongs to this bot, and cover human/peer-bot targets plus multi-workspace routing.
• Update the generated manifest and its tests alongside runtime registration.

Automated hermes-sweeper review.

[teknium1]

Merged via #70195 — your commit was cherry-picked/reapplied onto current main with your authorship preserved in git history: your reaction-pipeline forwarding (earliest, May 21) is the base commit with your authorship.

Thanks for the contribution!