beets-art: unpin from r1 + cap CPU to 1 (thermal fix)

The beets-art CronJob was hard-pinned to r1 via nodeSelector, and its
CPU limit was 2 (half the 4-core passively-cooled Beelink N100 on f1).
The daily noon fetchart/embedart sweep sustained ~35% CPU for ~28 min
and pushed f1 to ~95 C, tripping the FreebsdCpuTemperatureHigh alert
(>=80 C for 5m).

Two changes:

1. Cap the container CPU limit from 2 to 1. The run takes ~2x longer but
   stays well under the 6h activeDeadlineSeconds and roughly halves the
   sustained thermal load.

2. Unpin the CronJob from r1 so the scheduler can spread it. This is a
   manifest/config change, not a storage migration: the music library is
   already shared NFS (mounted at the same path on all three r-nodes).
   The only thing forcing r1 was the music PV/PVC being declared RWO
   (single-node mount) while shared with Navidrome, which is itself pinned
   to r1 by its local-path SQLite data PVC. Flip navidrome-music PV/PVC
   to ReadWriteMany so beets-art can mount it on any r-node alongside the
   read-only Navidrome pod.

   Also move beets-art-state from local-path (pinned to r1) to a static
   NFS-backed RWX PV/PVC so the job's SQLite state is reachable from any
   node. SQLite-over-NFS is acceptable here because concurrencyPolicy:
   Forbid guarantees a single writer (no lock contention), and the state
   is regenerable.

Application requires recreating the bound music PVC (access-mode changes
are immutable on a bound PVC) and the state PVC; see deploy notes.

0 files changed, 0 insertions, 0 deletions