fix(ui): keep the active conversation selected in the sidebar

[bndnsmth]

Why

In the main app's two-pane window, the sidebar could suggest that a different conversation was selected from the one displayed on the right. This is particularly misleading when composing a reply.

Reproduction confirmed on an installed client:

1. Focus the empty sidebar search field and press Down to place the keyboard cursor on the first chat.
2. Click a different chat.
3. Move the pointer out of the sidebar.

The conversation pane switches, but the first row can remain highlighted, or the clicked row loses all highlighting once hover ends. Expected: the displayed chat retains a persistent selected state.

The row backgrounds previously represented only hover or the keyboard cursor. openThread() did not synchronize that cursor, and neither pinned tiles nor chronological rows had a selected state tied to active.

What

Give pinned tiles and chronological rows in split view a persistent selected fill using Style.selectedFillFor(). Selection follows the displayed chat's identity through isShowing(), independently of pointer hover, editor focus, or list position. Explicit opens also synchronize the sidebar cursor and stop any pending preview timer, without calling cursorMoved() and scheduling another preview. Existing hover/cursor styling remains for other rows, and the flyout does not gain the split-view selected fill. Add source-level regression checks in the existing QML safety-invariant style and an Unreleased changelog entry.

How it was verified

• bun test is green (CI will check): 748 passing tests on current upstream main plus this fix.
• Any send/receive behavior was exercised against my own number only — never a contact or a group. N/A: no messages were sent during validation; this change does not alter send behavior.
• UI change → screenshot attached. Synthetic-data screenshots were inspected locally, but are not attached here.
• Touches an invariant in CLAUDE.md → named below, and the doc updated if it changed. No invariant changed; the existing "A peeked thread is not read" gate is preserved.

Behavioral checks:

• The affected user repeated the main-app click/move-pointer-away scenario after installing the patch and confirmed the selected state now persists.
• The isolated fake-bridge harness rendered the shipping view in split-view mode. With the pointer outside the sidebar and the keyboard cursor explicitly cleared, the displayed chat still retained its selected fill. Inspected both a pinned tile and an ordinary chronological row.
• No real conversations were opened by the automated checks, and no Mac-side tools or configuration were changed.

[nixfred]

Merged, thank you Brandon, and welcome. The sidebar pointing at one chat while the pane showed another is exactly the kind of quiet wrongness that bites when you are replying, and you tied the fill to the displayed chat's identity instead of hover or position, which is the right model. I checked the one thing I was worried about: moving the cursor in openThread() does not arm a preview (onCursorChanged only builds rows, previews start in cursorMoved()), so "a peeked thread is not read" still holds. 750 tests green, and both new tests fail against the old view. It is live on both my machines; I opened a pinned tile from outside the window and it keeps the selected fill with no hover.

One small ask: I thank contributors by name in a weekly post on X. Is there an account you'd like tagged? "Rather not be tagged" is an equally good answer.

[bndnsmth]

Appreciate the quick review and merge, @nixfred. Feel free to tag @bndnsmth in your post, thanks.