feat(webhook): dispatch message.reaction events (WebSocket/webhook parity)

[rmyndharis]

What

Message reactions were broadcast over WebSocket only — a webhook-only consumer could never observe reactions, an undocumented asymmetry (message.reaction was a subscribable WS event but not a webhook event).

Change

• Register message.reaction in WEBHOOK_EVENTS (among the dispatched events) and expose it in the dashboard event picker.
• Dispatch it from SessionService.applyReaction, alongside the existing WebSocket emit, with the same payload ({ messageId, chatId, reaction, senderId, reactions }, where reactions is the post-apply snapshot). Dispatch is fire-and-forget and happens only after the reaction is persisted.
• Add a dedicated idempotency-key case.

Idempotency

A reaction carries no unique id and is a read-modify-write of the message's reactions map — the same sender can re-apply the same emoji over time (👍 → remove → 👍). Keying on (sender, message) alone would collapse a genuine re-reaction onto the earlier one. The key is therefore salted with the per-dispatch occurredAt (captured once, reused across retries) — the same mechanism the recurring session.* lifecycle events use: distinct occurrences get distinct keys while retries of one delivery stay stable.

⚠️ Consumer-visible

Webhooks subscribed with the wildcard '*' will begin receiving message.reaction deliveries. Existing semantics for all other events are unchanged.

Tests

• idempotency.util.spec.ts: salt distinctness (re-reaction is a distinct event), retry-stability, two-sender distinctness.
• session.service.spec.ts: a reaction now dispatches message.reaction with the post-apply reactions snapshot.
• Backend lint + build + full jest (980) green; dashboard build + lint green. API spec updated.