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.

1 files changed, 12 insertions, 3 deletions

diff --git a/f3s/navidrome/helm-chart/templates/persistent-volume.yaml b/f3s/navidrome/helm-chart/templates/persistent-volume.yaml
index 3ca2867..3142c93 100644
--- a/f3s/navidrome/helm-chart/templates/persistent-volume.yaml
+++ b/f3s/navidrome/helm-chart/templates/persistent-volume.yaml
@@ -27,7 +27,16 @@ spec:
       storage: 10Gi
 ---
 # navidrome-music: keep on NFS — 200 GB library shared across nodes.
-# This is a static PV backed by hostPath at the NFS mount point.
+# This is a static PV backed by hostPath at the NFS mount point. The NFS
+# export is mounted at the same path on all three r-nodes (r0/r1/r2), so the
+# hostPath resolves identically on each node.
+#
+# ReadWriteMany (not RWO): Navidrome mounts this read-only as the library
+# reader; the beets-art CronJob mounts it read-write to fetch and embed cover
+# art. RWX lets beets-art run on any r-node (it no longer has to co-locate
+# with Navidrome just to satisfy RWO's single-node-mount rule). At the FS
+# level there is a single writer (beets-art; Forbid concurrency) and a single
+# reader (Navidrome), so no write contention.
 apiVersion: v1
 kind: PersistentVolume
 metadata:
@@ -37,7 +46,7 @@ spec:
     storage: 200Gi
   volumeMode: Filesystem
   accessModes:
-    - ReadWriteOnce
+    - ReadWriteMany
   persistentVolumeReclaimPolicy: Retain
   hostPath:
     path: /data/nfs/k3svolumes/navidrome/music
@@ -51,7 +60,7 @@ metadata:
 spec:
   storageClassName: ""
   accessModes:
-    - ReadWriteOnce
+    - ReadWriteMany
   resources:
     requests:
       storage: 200Gi