Fix idle watcher start race after PR #38

[marcmy]

What broke

PR #38 preserved the guard that pauses a compactor created after system activity resumes, but it still had a pre-compactor gap: an IdleOnly watcher run could be parsing when the system became active, then start background compression later because PauseCompacting() had nothing active to pause yet.

The runtime log reproduced this exact sequence: idle analysis started, the system became active, and background compression started roughly 30 seconds afterward. That leaves WatchedFolder.IsWorking true once the run reaches a long/paused folder, which is the progress ring visible in the watcher UI.

Fix

• Track whether the active watcher run was triggered by idle mode.
• Cancel only the pending idle-triggered watcher transition when activity resumes.
• Keep an already-running background compactor on the existing pause/resume path instead of cancelling it.
• Carry the watcher token down as a start-only gate so activity cannot slip through between parsing and compactor startup.
• Preserve PR Port worthwhile upstream fixes from Sep 1 #38's new-compactor pause inheritance, analyser ownership cleanup, process-priority restoration, and the other upstream ports.

The corrective diff is limited to Watcher.vb and BackgroundCompactor.vb; none of the custom charcoal/compression UI files are changed.

Verification

• Remote diff: 1 commit, 2 files only.
• git diff --check: clean.
• Build and Release Windows x64 workflow: passed.
• Supply-chain audit workflow: passed.
• Local restore was blocked before compilation by this sandbox's Windows/NuGet TLS credential failure (SEC_E_NO_CREDENTIALS); GitHub Actions completed the authoritative Windows build successfully.