Fix cover art embedded as a plain video stream

[kgrubb]

This fixes embedded cover art for non-MP3 output such as M4A. ffmpeg currently re-encodes the image as a normal video stream. Copying it and setting attached_pic makes players and library scanners recognize it as album art.

Verified with ffprobe on M4A output:

before: codec_name=h264   attached_pic=0
after:  codec_name=mjpeg  attached_pic=1

[Piero-93]

This fixes more than the title suggests: besides m4a, it also gets flac working (the image was silently dropped there) and stops mp3 from storing a re-encoded png.

Two things you may want to fold in:

1. The picture type stays 0 ("other") rather than 3 ("front cover"). Adding "metadata:s:v": []string{"title=Album cover", "comment=Cover (front)"} gives type 3.
2. c:v copy can cost the whole track: the cached file is named .jpg but holds whatever the CDN served, and a WebP under that name fails the mp4 muxer (Could not find tag for codec webp in stream Wrong track added to playlist #1), which makes saveVideo return false. c:v mjpeg handles that case and re-encoding a still image is cheap.

Heads-up on overlap: the cover only becomes an ffmpeg input inside the track.CoverPath == "" branch, and loadCustomTracks fills CoverPath from the playlist cache — so for playlists imported through the web UI there is no picture stream for attached_pic to flag in the first place. I opened #230 for that, which ends up covering this ground too. Either order works for me: I can rebase on top of this one, or drop the overlapping part if this gets merged first.

[kgrubb]

good catches, thanks! folded both of those recommendations into this branch. Regarding the overlap with #230, either order works for me. Happy to rebase or drop the overlapping part if that one lands first.