fix: select a launch's row whatever the keyboard last held

A --message launch handed to a window already in use switched the list
to the conversation and made the reply row current, and the message
pane stayed empty. The same launch into a fresh window worked.

selectRowAt() selected the row and then called the view's
setCurrentIndex(). QAbstractItemView::setCurrentIndex() asks
selectionCommand() what to do with the selection, and with no event to
read it answers from QGuiApplication::keyboardModifiers(), which is the
modifier state of the last input event the application received rather
than anything the user is doing now. With Control in that state the
command is a Toggle: the row selected a line earlier was deselected
again, onThreadSelected() refused a current row that is not selected,
and nothing was loaded. The provisional thread row the recovery selects
first went the same way, so the pane never left the placeholder. A
fresh process has received no input at all, which is why only a window
in use was affected.

The current index is now moved through the selection model with
NoUpdate, so the selection stays exactly what select() made it. Every
caller of selectRowAt() shared the defect (the stale-thread recovery,
double-click, the dashboard's message entries and the launch selectors)
and every one of them means "select exactly this row", so all of them
take the fix.

The test puts a window into use, leaves Control as the last modifier
the application saw, launches --message for a reply in another thread,
and asserts the reply is current, selected, and rendered in the pane.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions