fix(mining): restore the miner after a benchmark only if it was running

Cancelling a thread benchmark always stopped and restarted the pool
miner at its pre-benchmark thread count, even when the user had not been
mining before the benchmark began. That silently started the miner on a
plain cancel or a switch to solo mode.

- A cancel now always drops the candidate-thread miner, and restarts the
  pool miner only when the user was mining before the benchmark, read
  from a snapshot taken at the start rather than the live running state
  (the benchmark sweep transiently stops the miner between candidates,
  so a live check would drop the restore).
- Callers that must not restore the miner (leaving solo mode) pass the
  new restore flag as false.

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

src/ui/windows/mining_benchmark.h

@@ -59,6 +59,15 @@ struct ThreadBenchmarkUpdate {
     bool inconclusive = false;  // finished with no nonzero hashrate sample — caller should warn
 };
 
+// What a user-initiated cancel of an active benchmark must do with the miner. Always drop the candidate-thread
+// miner; restart only if the user was mining BEFORE the benchmark (snapshot, not live state - the sweep
+// transiently stops the miner, so a live check would drop the restore, L-04/L-11).
+struct ThreadBenchmarkCancel {
+    bool restartMiner = false;
+    int  restartThreads = 0;
+};
+ThreadBenchmarkCancel PlanThreadBenchmarkCancel(const ThreadBenchmark& benchmark);
+
 ThreadBenchmarkUpdate AdvanceThreadBenchmark(ThreadBenchmark& benchmark,
                                              float deltaSeconds,
                                              double poolHashrate10s);