[Bug] Scope message selection to the active conversation

[assagman]

In the macOS desktop app, native text selection can include content outside the user's intended scope:

• In split view, dragging from channel content into a thread selects both channel and thread content.
• Dragging across a message can select hover quick-reaction emojis and inline reaction pills.
• Popup/overlay content can also participate in selection.

Steps to reproduce

1. Open a channel with a threaded message.
2. Open the thread in split view.
3. Drag-select from a channel message into a thread reply.
4. Hover a message and drag-select across its action area.
5. Repeat on a message with reaction pills.

Expected behavior

• Channel selection remains inside the channel.
• Thread selection remains inside the thread.
• Message text remains copyable.
• Hover action bars, quick reactions, reaction pills, emoji pickers, reaction popovers, and other interactive overlays are excluded.
• Timestamps and ordinary message metadata may remain selectable.

Version and platform

• Buzz desktop source/config version: 0.5.3
• Source commit: b1b283cd4
• macOS 26.6 (build 25G5065a), Apple Silicon arm64

Logs / additional context

Current selection behavior example:

[iroiro147]

PR #4105 addresses the chrome-contamination half of this issue.

• Root cause confirmed: zero select-none / user-select on any interactive message chrome — the hover action bar, quick-reaction buttons, reaction pills, and inline add-reaction trigger were all selection-transparent, so a native macOS drag-select swept them up along with message text.
• Fix: added Tailwind select-none to the two interaction roots — MessageActionBar (desktop/src/features/messages/ui/MessageActionBar.tsx:438) and MessageReactions (desktop/src/features/messages/ui/MessageReactions.tsx:247). user-select: none propagates to children, so quick reactions, the more-actions menu, reaction pills, the inline picker trigger, and the emoji-picker popover are all excluded.
• Out of scope for this PR: full channel↔thread selection isolation in split view would require clipping selection at component boundaries (user-select: contain is not universally supported). Suggest evaluating a follow-up based on real-world reports after this lands.
• Out of scope: message bodies, timestamps, and ordinary metadata remain selectable per the issue's expected behavior — only overlaid interactive chrome is excluded.
• Verification: tsc --noEmit clean; build:e2e clean; reaction-order / inbox-reactions playwright specs fail identically on unmodified main (pre-existing env flake, unrelated to this change). Manual macOS reproduction would confirm drag-select now stops at the chrome boundary.

[iroiro147]

Fixed in #4272.

Root cause: the conversation split view never scoped native drag-selections, so a selection starting in one pane could cross into sibling panes and pull in hover chrome (action bars, quick reactions, reaction pills, emoji pickers, popovers) along the way.

The fix:

• Channel / thread / right-auxiliary panes now carry a data-selection-pane marker.
• Hover chrome and overlays that must never participate in a selection are marked data-selection-exclude + select-none.
• A useConversationSelectionScope hook on the shared conversation root listens for selectionchange; once a drag is anchored inside a pane, the escaping focus end is clamped back to the pane boundary — so channel selection stays in the channel, thread selection stays in the thread.
• Message text, timestamps, and ordinary metadata remain selectable; composers, inputs, contenteditables, and dialogs/popovers keep their native behavior.