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.cpp

@@ -88,6 +88,14 @@ bool ThreadBenchmark::active() const
     return phase != Phase::Idle && phase != Phase::Done;
 }
 
+ThreadBenchmarkCancel PlanThreadBenchmarkCancel(const ThreadBenchmark& benchmark)
+{
+    ThreadBenchmarkCancel plan;
+    plan.restartThreads = benchmark.prev_threads;
+    plan.restartMiner   = benchmark.was_pool_running && benchmark.prev_threads > 0;
+    return plan;
+}
+
 ThreadBenchmarkUpdate AdvanceThreadBenchmark(ThreadBenchmark& benchmark,
                                              float deltaSeconds,
                                              double poolHashrate10s)