Fix bottleneck analyser, duplicate console output, and add CPU affinity

[rasmusjen]

Found while running a full end-to-end validation of the pipeline: 7 days per
year, 3 years, two sites (GL-ZaF at 10 Hz, GL-Dsk at 20 Hz), every run repeated
after a discarded warm-up.

Fixes

The bottleneck analyser could not detect a CPU bottleneck. monitor.py
divides process-tree CPU by the logical core count, so a single-threaded
EddyPro saturating one core of twenty recorded ~5% against 70/90% thresholds.
Every run came back NONE: no clear bottleneck ... headroom to increase max_processes — correct only by coincidence, and identical to what it would
say on a fully saturated machine. Measured on a real run:

Signal	p95
cpu_percent (÷20)	5.0% — what the classifier saw
cpu_percent_of_core	100.3% — pegging one core
system_cpu_percent	23.1% — machine 77% idle

Now judges machine saturation on system_cpu_percent (the only column a
parallel worker can see the whole machine through) and adds a
CPU_SINGLE_CORE verdict. Falls back to the old figure when the system column
is absent, so older metrics files stay classifiable.

EddyPro output was written to the console twice. setup_logging always
attaches a stdout handler, so with the shipped defaults the streaming loop's
print() duplicated every logged line: 44 560 log lines per site-year before,
22 196 after.

The format hook never ran. It invoked sys.executable — the system Python,
which has no black or ruff — and its tolerate-missing path only caught
FileNotFoundError, so every edit exited 2 with "No module named ruff".

Additions

cpu_affinity config option. On hybrid CPUs the OS parks long-running
background work on the efficiency cores. eddypro_rp is single-threaded, so
one year of 10 Hz data took 241 s pinned vs 474–501 s unpinned — and CPU
monitoring cannot see it, because a saturated E-core reads the same ~100% of a
core as a saturated P-core. Pinning also removed run-to-run variance entirely.
Accepts performance (auto-detect), an explicit CPU list, or null (default,
unchanged).

Throughput signal. work_items / work_items_per_s from the
binned-cospectra count, plus mean_seconds_per_work_item in the report. This
is what makes the above detectable: identical CPU, half the work done.

Validation results

Multiprocessing scales cleanly across years — 2.80× on 3 workers (GL-ZaF,
93% efficiency), 2.93× (GL-Dsk, 98%) — and output is byte-identical to
sequential across all 24 files compared. Disk peaked under 10 MB/s against a
450 MB/s threshold and memory at 29 MB per worker, so neither constrains
anything. Monitoring overhead is below run-to-run noise.

Also worth recording: 20 Hz data costs 3.6× more than 10 Hz, not 2×.

Notes for review

• CPU_SINGLE_CORE is a new value for primary_bottleneck; nothing in-repo
  parses it, but downstream consumers of the manifest would see it.
• The throughput signal points at eddypro_binned_cospectra, which only exists
  when spectral output is enabled. Without it work_items stays 0 — it
  degrades quietly rather than erroring, so the diagnostic is not universal.
• Affinity auto-detection assumes the standard Windows enumeration where P-core
  threads are numbered first. It returns None rather than guessing when the
  topology is unexpected.

221 tests pass; ruff, black, mypy and the pre-commit suite clean.