fix: show the account's startup view for a lone --account

The account dropdown deliberately does not re-run the query: by hand the
user picks a filter next. A launch from another program has no next click,
so `--account work` on its own moved the dropdown and changed nothing the
user could see.

When the account selector applies and no thread or message was given, the
startup view now runs again in the new account. The constructor's startup
path moves into runStartupView() and both callers use it, so the view is
resolved the same way in each: a generated filter is asked for the
account's own query rather than having its all-accounts query wrapped in
the account's path.

The test starts on the trash view because its per-account query is the
account's own trash path; for a tag filter the generated and the wrapped
queries are the same string, and a test on one passed against the wrap.
It asserts on the generated string and on the rows, and fails with the
wrap put back.

anEmptySelectorSetChangesNothing also asserts that no query ran, which the
bar and the dropdown alone cannot show.

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

1 files changed, 26 insertions, 1 deletions

diff --git a/src/mainwindow.cpp b/src/mainwindow.cpp
index c44e36d..3ae16e9 100644
--- a/src/mainwindow.cpp
+++ b/src/mainwindow.cpp
@@ -654,13 +654,24 @@ MainWindow::MainWindow(const Config &config, QWidget *parent)
             m_accountBox->setCurrentIndex(index);
     }
 
+    runStartupView();
+}
+
+void MainWindow::runStartupView()
+{
+    // The dropdown's account, which the constructor has just set from
+    // startup_account and applySelectors() from --account. Read rather than
+    // passed, because the dropdown is what runQuery() scopes with below, and
+    // two sources for one scope is how they come to disagree.
+    const QString accountKey = m_accountBox->currentData().toString();
+
     // resolvedQuery(), not startup.query: a generated entry stores no query at
     // all, since its text is composed from the accounts at run time. Reading
     // the field directly meant a startup_query naming a built-in filter opened
     // an empty bar and ran nothing.
     const SavedQuery startup = m_config.startupSavedQuery();
     const QString startupQuery =
-        m_config.resolvedQuery(startup, startupAccount);
+        m_config.resolvedQuery(startup, accountKey);
     if (!startupQuery.isEmpty()) {
         m_queryEdit->setText(startupQuery);
 
@@ -5267,6 +5278,20 @@ void MainWindow::applySelectors(const LaunchSelectors &requested)
             showTransientStatus(
                 tr("No account named '%1'.").arg(selectors.account));
         }
+
+        // The account on its own is a request for that account's VIEW, and
+        // moving the dropdown is not one: by design the dropdown only rescopes
+        // the filter buttons and leaves the list alone until the user clicks
+        // one, and a launch from another program has no next click. So the
+        // startup view runs again, resolved for the new account.
+        //
+        // Not when a thread or message was given, whose own query is about to
+        // replace the list; running this too would race it.
+        if (index >= 0 && selectors.threadId.isEmpty()
+            && selectors.messageId.isEmpty()) {
+            runStartupView();
+            return;
+        }
     }
 
     // A message id names a message INSIDE a conversation, so it has to be