fix: give playlists the mirror's ownership rather than root's

Playlists were being written owned by root. The image runs as root by default,
deliberately, so that a bind-mounted dataset of any ownership stays writable --
but everything it writes then comes out root-owned, and a root-owned playlist
inside a mirror owned by the apps account is unreadable to whatever serves it.
The group-read bit does not help when the group is also root.

Copy the ownership of the mirror the playlist is being written into. That needs
no configuration, cannot drift from whatever the mirror actually is, and does
nothing at all when the two already agree -- which is the case whenever the
container is run with an explicit user.

Applied to the temporary file before the rename, so a playlist is never briefly
visible owned by the wrong account, and to the _playlists directory when this is
the run that creates it. A chown that is refused is ignored rather than fatal:
that only happens when not running as root, which is precisely the case where
the ownership was already right.

README.md

@@ -261,6 +261,13 @@ in step by hand. Override it if that guess is wrong.
 Entries are written **relative to the playlist file**, so one playlist works
 from the NAS, from a Mac over SMB, and from Linux, without rewriting.
 
+Each playlist is given the **owner and group of the mirror** it is written
+into. The image runs as root by default so that a bind mount of any ownership
+stays writable, and the cost of that is output owned by root — which the account
+serving the share cannot read, group bit or no group bit, because the group is
+also root. Copying the mirror's own ownership avoids having to be told what it
+should be, and does nothing when the two already agree.
+
 A track is only listed once its mirror file has been confirmed to exist. Lidarr
 holding the FLAC says nothing about whether the MP3 has been encoded yet. If a
 large number are missing, the run says so — that is what a wrong `--library-root`