fix(music): base an appended m3u path on the playlist, not the music root

cj/music--append-track-to-m3u-file wrote every relative path against
cj/music-root wherever the playlist actually sat. Both readers resolve
against the playlist's own directory: cj/music--m3u-file-tracks, and EMMS's
emms-source-playlist-parse-m3u. So the writer and the readers disagreed
whenever those two directories were not the same one.

That is not only the playlist-outside-the-music-root case I went looking
for. 39 of the 66 m3u files under ~/music are album playlists sitting beside
their tracks, storing bare filenames. Appending to any of them wrote a line
like Artist/Album/track.flac that resolved to a path which never existed.

The fix is the base: (file-name-directory m3u-file).

Worth recording how the tests went, because the first three I wrote all
passed against the broken writer. I had put cj/music-root and the playlist
directory at the same depth, so file-relative-name returned the same string
for both bases. The fixture reached the bug's code path and still could not
see it. The discriminating cases put the two bases at different depths, and
reverting the one-line fix now fails them.

Eight existing tests moved with it. They built track paths from the real
cj/music-root while the playlist sat in a temp directory, which pinned the
old base and also read my actual music root. Rebinding the root to the
fixture directory restores every assertion verbatim and makes them hermetic.

One thing this does not change: MPD resolves relative playlist entries
against music_directory and rejects entries that escape it, so a ../ line is
for EMMS rather than MPD. That costs nothing today, since EMMS drives mpv
here and MPD is not running.

0 files changed, 0 insertions, 0 deletions