Story: Make UI more responsive

The NATS request/reply calls are already wrapped in QtConcurrent::run() + QFutureWatcher throughout the Qt layer. The UI thread is never directly blocked by a synchronous NATS call. However, several interacting issues make dialogs feel slow and unresponsive.

Every dialog that makes async NATS requests cleans up its watchers in the destructor like this:

CurrencyDetailDialog::~CurrencyDetailDialog() {
    const auto watchers = findChildren<QFutureWatcherBase*>();
    for (auto* watcher : watchers) {
        disconnect(watcher, nullptr, this, nullptr);
        watcher->cancel();
        watcher->waitForFinished();  // BLOCKS the UI thread!
    }
}

waitForFinished() blocks the calling thread (the UI thread, since destructors run on the owning thread) until the background NATS request completes. If the user opens a dialog and immediately closes it, or rapidly switches between dialogs, each close blocks the UI until all in-flight NATS requests finish.

Affects: CurrencyDetailDialog, CurrencyHistoryDialog, CurrencyMdiWindow, and every other detail/history/list window in ores.qt.refdata, ores.qt.party, ores.qt.admin, ores.qt.analytics, etc.

DetailDialogBase and HistoryDialogBase have no loading state infrastructure at all — no spinner, no overlay, no "Loading…" text. When a dialog opens, the user sees:

1. An empty window with no feedback
2. Combo boxes populate asynchronously (pop-in effect)
3. The user has no way to distinguish "loading" from "broken"

By contrast, EntityListMdiWindow has beginLoading() / endLoading() and a QProgressBar, but even that is an indeterminate marquee bar — not a spinner icon or overlay.

Concrete example: CurrencyDetailDialog::setClientManager() fires up to 4 concurrent async NATS requests to populate combo boxes and check feature flags, but nothing tells the user work is in progress.

Every detail dialog calls setClientManager() from the controller, which fires populate*Combo() methods asynchronously. The combo box starts empty, and when the future completes, it is cleared and repopulated. The result is a jarring pop-in effect where fields appear one by one.

Concrete example in CurrencyDetailDialog::setClientManager():

void CurrencyDetailDialog::setClientManager(ClientManager* clientManager) {
    clientManager_ = clientManager;
    if (clientManager_) {
        // ...
        if (clientManager_->isConnected()) {
            populateRoundingTypeCombo();      // 1 NATS request
            populateMonetaryNatureCombo();    // 1 NATS request
            populateMarketTierCombo();        // 1 NATS request
        }
    }
}

Each populate*Combo() method does:

void CurrencyDetailDialog::populateRoundingTypeCombo() {
    QFuture<FetchResult> future = QtConcurrent::run([self]() -> FetchResult {
        auto req = refdata::messaging::get_rounding_types_request{};
        auto result = self->clientManager_->process_authenticated_request(std::move(req));
        // ...
    });
    // On completion: clear() + re-add items
}

The QThreadPool used by QtConcurrent::run() defaults to QThread::idealThreadCount() threads (typically 8-16). Every async NATS request blocks one of those threads waiting for the network round-trip.

At application startup (on loggedIn signal), the following async loads fire concurrently:

Then when a user opens a dialog:

With multiple entity types and windows, the thread pool can become saturated with I/O-blocked threads, causing queued requests to wait and increasing latency for every dialog.