freesailarr: one volume entry per media claim (2.0.2+up1.0.0)

media.downloads, media.movies and media.tv rendered three fixed volume
entries, one per category. Two categories on the same existingClaim
therefore produced two pod volumes with an identical claimName, and such a
pod never starts: it stays in Init:0/1 without a single kubelet event
(measured on RKE2/Longhorn, RWO and RWX alike).

The volume list is now deduplicated by claim name. A new mediaVolumeName
helper names the entry after the first ENABLED category in the fixed order
downloads, movies, tv that carries the claim; the other categories mount
that same entry and differ only in their subPath. The restriction to
enabled categories matters because the three entries render under
different conditions - a canonical owner whose entry is not rendered would
be a dangling reference.

With three distinct claims the chart renders byte-identically to 2.0.1,
hence a patch bump.

Also corrected in the values documentation, after measuring instead of
assuming: the kubelet creates missing subPath directories itself, but they
inherit the claim root's mode, and fsGroup cannot be relied on to fix that
- Longhorn's fsGroupPolicy (ReadWriteOnceWithFSType) skips fsGroup on RWX
claims entirely. What has to hold is that the claim root is writable for
PUID/PGID. No chown or init container was added.

freesailarr/templates/NOTES.txt

@@ -87,10 +87,12 @@ THE MEDIA CLAIMS ARE YOURS, THE CONFIG VOLUMES ARE THE CHART'S
   Kubernetes makes every volumeMount its own bind mount and link() across two
   mount points fails with EXDEV regardless of subPath, so an import copies.
 
-  The containers write as {{ .Values.puid }}:{{ .Values.pgid }}. If the claims already hold data
-  owned by someone else, fix the ownership before the first start — the pod
-  will not do it for you (fsGroupChangePolicy is OnRootMismatch, deliberately,
-  so a large library is not recursively re-chowned on every start).
+  The containers write as {{ .Values.puid }}:{{ .Values.pgid }}. The claim's root directory has to be
+  writable for them, and a subPath directory the kubelet creates inherits that
+  root's mode — so fix the ownership before the first start. The pod will not
+  do it for you: fsGroupChangePolicy is OnRootMismatch so a large library is
+  not re-chowned on every start, and on an RWX claim a driver like Longhorn
+  (fsGroupPolicy ReadWriteOnceWithFSType) ignores fsGroup altogether.
 {{- if eq $replicas "0" }}
 
 SCALED TO ZERO