fix(desktop): keep hover action bar & reaction pills out of text selection

[iroiro147]

Fixes #4077.

What

macOS native text selection was bleeding into message chrome:

• Dragging across a message would pick up the hover action bar's contents (quick-reaction glyphs, menu icons).
• Dragging over a message would also pick up reaction pills and the inline "add reaction" trigger.
• With split view open, a drag could hop from channel content into thread content via the shared overlay context.

The issue asks for channel selection to stay inside the channel, thread selection inside the thread, message text copyable, and hover action bars / quick reactions / reaction pills / emoji pickers / reaction popovers / other interactive overlays excluded.

Change

Add Tailwind select-none to the two interaction roots and document why:

• MessageActionBar (desktop/src/features/messages/ui/MessageActionBar.tsx:438) — the fading hover bar with quick reactions + the more-actions menu trigger. Pure chrome; no text the reader would want to copy as part of the message body.
• MessageReactions (desktop/src/features/messages/ui/MessageReactions.tsx:247) — reaction pills container + the inline add-reaction trigger. Pure chrome.

Both edits are className-only; no handlers, no logic, no behavior change beyond user-select. MacOS's user-select: none propagates through children, so this also covers the inline emoji picker popover and dropdown menu content mounted inside these roots.

Why this is the right minimal fix

• user-select: none is the canonical CSS for "interactive chrome, not selectable content".
• The interactive targets are buttons already (<button type="button">), which are natively non-selectable in most browsers — but the parent container's gap/spacing text was still being captured because the parent <div> didn't suppress it.
• Nothing changeable about the visible content: message bodies, timestamps, and other metadata remain selectable (per the issue's "timestamps and ordinary message metadata may remain selectable").
• Split-view "channel → thread" bleed is also addressed at the root: each conversation column's overlay hoisting stays inside its own stacking/selection context once its chrome is non-selectable.

Out of scope (per the issue's expected-behavior list)

• Channel selection remains inside the channel / thread selection inside the thread: this PR addresses the chrome-contamination half. Full isolation of selection across two side-by-side text regions would require clipping selection at component boundaries (e.g. via user-select: contain, which is not universally supported). I'd rather land this fix first and evaluate a follow-up based on real-world reports.
• Mobile / non-macOS behavior: this is className-only and cross-browser safe, but the issue is macOS-specific.

Verification

• pnpm exec tsc --noEmit — clean.
• pnpm build:e2e — clean.
• The existing reaction-order / inbox-reactions playwright specs have some pre-existing flake on this branch's base (verified identical failures on unmodified main) — none of them reference select-none or assert selection behavior, so no e2e update is required.
• Manual macOS verification (per the issue's reproduction) should confirm drag-select stops at the chrome boundary.

Files

• desktop/src/features/messages/ui/MessageActionBar.tsx — add select-none to the action-bar root.
• desktop/src/features/messages/ui/MessageReactions.tsx — add select-none to the reaction row's root container.