fix: embed cover art when the cover is already on disk

[Piero-93]

The bug

With EMBED_COVER_ART=true, the cover is added as an ffmpeg input only inside the track.CoverPath == "" branch of saveVideo, that is, only when it still has to be downloaded:

if c.Cfg.EmbedCoverArt && track.CoverURL != "" {
    if track.CoverPath == "" {
        if _, track.CoverPath = util.DownloadCover(...); track.CoverPath != "" {
            streams = append(streams, ffmpeg.Input(track.CoverPath))
        }
    }

loadCustomTracks fills CoverPath from the playlist cache, so for any custom playlist imported through the web UI (Spotify, Apple Music, ListenBrainz link) the image is already on disk when the download starts. The branch is skipped, the image never reaches ffmpeg, and EMBED_COVER_ART silently does nothing. Signature in the logs: an ffmpeg command with a single -i.

The fix

Fetching the cover and handing it to ffmpeg are now separate steps, and how the image is embedded depends on what the output container can hold:

container	how
mp3, flac, m4a, m4b, mp4	attached picture stream, re-encoded to mjpeg and flagged attached_pic
ogg, oga, opus, spx, wv	base64 METADATA_BLOCK_PICTURE tag
anything else (wav, aac, ac3, aiff, mka, webm)	no artwork

Three failure modes that currently cost the whole track, not just the artwork, are gone as well:

• wav, aac and ac3 lose the track today. Those muxers cannot hold an image, so passing one fails the entire command (wav muxer does not support any stream of type video) and the download never lands.
• DownloadCover returns its destination path even when the fetch failed — the return sits outside the status check — so a 404 or an empty body yields a non-existent input and a failed command. The file is now checked to exist and to be non-empty. I left the helper's signature alone, since the web UI depends on its current contract.
• If ffmpeg refuses the image for any other reason, the file is written a second time without it. Artwork can no longer cost a track.

Two smaller corrections in passing:

• ffmpeg.Input(input).Audio() replaces the explicit "map": "0:a", which was only set on the branch without cover art. With two inputs the library maps every input, so a video stream in the downloaded file used to survive into the output.
• -metadata:s:v title/comment gives the picture type 3 ("front cover"); without them ffmpeg writes type 0 ("other").

On mp4 the image is currently stored as an h264 video stream, and on mp3 as a re-encoded png. #219 reports the mp4 half of this and fixes it inside the old branch; here it falls out of the table above. Happy to rebase on top of #219, or to drop the overlapping part, if you would rather merge that one first.

Verification

Files written and artwork read back with a tag library, on ffmpeg 7.0.2, 8.1.2 and 9.0.1, with identical results on all three: 96 combinations of 16 containers by 6 cover inputs (jpeg, png, webp, truncated, empty, missing). No track lost in any of them, and picture type 3 wherever the container allows one.

Three judgement calls worth flagging:

• mjpeg rather than copy. The cached file is named .jpg but holds whatever the CDN served; copying a WebP into mp4 fails with Could not find tag for codec webp, and re-encoding a still image is cheap. On the Vorbis comment path a WebP is skipped instead, with a warning, since there is no stdlib decoder for it.
• aiff, mka and webm are left out deliberately. ffmpeg accepts the command, but the artwork cannot be read back afterwards.
• The METADATA_BLOCK_PICTURE tag travels as a command-line argument, which Linux caps at 128 KiB each, so covers whose encoded tag exceeds 100 KiB are skipped. The default COVER_ART_SIZE=250 stays an order of magnitude below that.