[Refactor] Normalize chat reaction task entry

[roomote-roomote]

Created by Roomote. Follow up by mentioning @roomote-roomote or in the web UI.

What changed

Introduced one typed reaction task-entry contract for Slack, Discord, and Microsoft Teams. Provider reaction ingress now passes explicit requester, source event, target message/thread, and prompt data into the existing active-task, resume, and fresh-launch orchestration paths instead of forging provider message events.

Discord reactions no longer recurse through a synthetic MESSAGE_CREATE, Teams reactions no longer mutate activities into messages, and Slack keeps reaction identity separate from the target used for thread context and acknowledgements. Pending Discord account-link requests persist the typed entry so the original reaction intent survives continuation.

Why this change was made

Provider event emulation spread reaction-only state through already complex chat handlers and gave the same fields conflicting identity, context, and acknowledgement roles. An explicit boundary keeps future task-entry modes from requiring more synthetic provider payloads and optional state.

Impact

There is no intended user-facing behavior change. Configured chat reactions continue to queue follow-ups, resume eligible tasks, or launch new tasks with the same prompt and target context, while the orchestration is now typed, consistent across providers, and easier to extend safely.

[roomote-community]

1 issue outstanding. See task

• apps/api/src/handlers/teams/index.ts:1683-1729 Preserve the typed reaction entry through the Teams account-link flow. An unlinked user gets an auth token containing the unchanged messageReaction; after linking, resumePendingTeamsAuthToken only builds a queue message for message activities and returns unsupported_activity, so the configured reaction is silently lost.

_{Reviewed 1bbfada}