Offline playlists downloads songs separate from its respective album

[SindreKjelsrud]

Describe the bug
Offline playlists now download songs as part of the playlist's own album, causing duplicate downloads if the same song is in its original album - downloaded for offline as well. This results in inefficient storage usage and redundant downloads.

To Reproduce
Steps to reproduce the behavior:

1. Download both a playlist with one song that you can also download in an album, and its respective album.
2. Go into Preferences
3. See that Downloaded Songs is more than needed.

Expected behavior
When downloading a playlist for offline usage, it also downloads its connected album (even if it's only one song).

Context (please complete the following information):

• Device: iPhone 13
• OS: iOS 17.6.1
• Navidrome Version 0.54.3 (734eb30a)
• flo Version 1.6.0 (163)

[faultables]

yes i'm aware of this issue, and keep in mind that when downloading a playlist, flo will also downloads the album cover for every track in that playlist, that adds more redundancy

the thing is, flo uses this directory structure:

.
└── Media/
    ├── [Artist Name]
    │   └── [Album Name]
    │       ├── Track 1
    │       ├── Track 2
    │       ├── Track 3
    │       └── cover.jpg
    └── Various Artists/
        └── [Playlist Name]
            ├── Track 1
            ├── Track 2
            └── [album_id].jpg

so let's say we do this:

• Download a playlist, Song B is from Artist C in Album A, so now we have Media/C/A/B
• We open Album A, the download status should be "Downloaded" because it is
• We delete the album from the local: 1) We don't want that action is affecting the downloaded playlist 2) the "you can't delete this album because this is part of the playlist" is somewhat bad ux 3) fake "downloaded/deleted" status may fix known thing but may cause another unknown thing
• We delete the downloaded track from the playlist: basically same with the above

The standard for playlist is by using m3u but i'm not really familiar with that currently (and not sure if it works well in iOS (or flo at the time) both for remote/local streaming).

But we'll keep this issue open, especially until we have a better idea to fix this