perf(mining): one save, at most one restart per thread-count gesture

Every thread-count change on the Mining tab saved settings.json and,
with a miner running, stopped and restarted it: xmrig re-inits its
RandomX dataset and reconnects to the pool, seconds of lost hashing
each time. A drag across the grid did this once per tile crossed (up to
~24), with a "Starting pool miner" toast each; every -/+ click or Enter
did it again.

The tab now hands each pick to the App, which puts the newest in
settings at once and applies it when the input settles: on drag
release, or 0.5 s after the last click, even if the Mining tab was left
in the meantime. The header, RAM estimate and tile fill still follow
the drag live.

- Pool: the restart is decided on the mining-control thread, after every
  earlier start or stop has run. It never starts a miner the user
  stopped, is a no-op when xmrig already runs at that count, and is no
  longer silently skipped when the pick lands in another restart's stop
  window (which left xmrig on the old count).
- Solo: one setgenerate per gesture. A pick made while one is in flight
  now waits for it instead of being dropped (another stale count).
- Clicking the tile that is already selected does nothing; it used to
  save settings and restart the miner.
- With idle thread scaling on, the grid no longer snaps back to the old
  count while a pick is on its way to the miner. A pool auto-balance
  restart keeps a count still queued.
- Idle thread scaling changes the pool count through the same retarget.
  Its correction after a start compares with the count last requested,
  not the xmrig API's lagging report, so it comes about 1 s in instead
  of after the first API report (3-5 s).
- A retarget whose pool config no longer validates shows the same error
  and stops the miner, as the old stop-then-start did.
- While a benchmark runs a pick is saved, but the miner change is
  dropped: the benchmark owns the count until it ends.

A crash within 0.5 s of a pick, or mid-drag, loses that pick; every
clean exit saves it.

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

src/ui/windows/mining_tab.cpp

@@ -140,16 +140,19 @@ static void RenderMiningTabContent(App* app)
 
     // Sync thread grid with actual count when idle thread scaling adjusts threads
     // Skip during benchmark — the benchmark controls thread counts directly
-    if (app->settings()->getMineWhenIdle() && app->settings()->getIdleThreadScaling() && !s_drag_active && !IsMiningBenchmarkActive()) {
+    // ...nor while a thread-count pick is still on its way to the miner (the grid would snap back to the old count).
+    if (app->settings()->getMineWhenIdle() && app->settings()->getIdleThreadScaling() && !s_drag_active &&
+        !app->miningThreadCommitPending() && !IsMiningBenchmarkActive()) {
         if (s_pool_mode && state.pool_mining.xmrig_running) {
-            // Use the requested thread count (available immediately) rather
-            // than threads_active from the xmrig API which lags during restarts.
-            int reqThreads = app->getXmrigRequestedThreads();
+            // Use the requested thread count (available immediately) rather than threads_active from the
+            // xmrig API, which lags during restarts; the App's target also covers a restart still queued.
+            const int queued = app->poolThreadsTarget();
+            int reqThreads = queued > 0 ? queued : app->getXmrigRequestedThreads();
             if (reqThreads > 0)
                 s_selected_threads = ClampMiningThreads(reqThreads, max_threads);
             else if (state.pool_mining.threads_active > 0)
                 s_selected_threads = ClampMiningThreads(state.pool_mining.threads_active, max_threads);
-        } else if (mining.generate && mining.genproclimit > 0) {
+        } else if (mining.generate && mining.genproclimit > 0 && !app->isMiningToggleInProgress()) {
             s_selected_threads = ClampMiningThreads(mining.genproclimit, max_threads);
         }
     }