Cover hot reload and a watcher-disabled config in the effective-payout tests #656

What's the problem

#630's third acceptance criterion is still open after PR #648 fixed the first two: the effective-payout tests do not compare pool identity, account for XMRig's hot reload of the generated config, or cover a configuration with the watcher disabled. Stock XMRig watches the config file RigForge generates (systemd/xmrig.service.template), so a pool change can take effect without the restart these tests assume.

What it impacts

Test coverage of payout changes: a regression in how a new payout reaches a running miner (reload versus restart, watcher on or off) would not be caught.

How I found it

Split from #630 on 2026-11-07 by the owner's ruling for RigForge 1.18.1: #630 closes for criteria 1 and 2 (PR #648, merged as b82758b), and this criterion moves to the next release. The worker's note on #630 (2026-11-06) records that the watcher-disabled configuration exists only once watch: false generation lands in #529 / PR #608.

How important is it

Minor: test coverage for behaviour the 1.18.1 fix already corrects. It cannot be done before #529.

Acceptance criteria

1. The effective-payout tests compare the pool identity the miner actually uses, not only the generated file.
2. They account for hot reload with the watcher on.
3. They cover an explicit watcher-disabled configuration once XMRig rewrites and hot-reloads the config RigForge owns: autosave is forced on and watch is left at its default #529 generates it.
4. The suite passes.

Possible solutions

Add the cases to the existing apply/payout tests once #529 (PR #608) lands, reusing the restart-rejection fixture from #648.