Fixed album cover retrieval process

[BernardMaacaron]

# Title
Prefer square album artwork by adding alternative cover retrieval and square fallback processing

## Description
This PR updates how album artwork is resolved and embedded during downloads.

Previously,  the downloader would fall back to the matched YouTube video's thumbnail metadata. Since those thumbnails are often landscape, downloaded tracks could end up with embedded artwork that was not square and did not reliably match the actual release.

This change improves that behavior by:
- preferring album artwork from YouTube Music when album metadata is available
- falling back to MusicBrainz + Cover Art Archive when YouTube Music album art cannot be resolved
- square-cropping and normalizing the final fallback image before embedding, so even video-thumbnail fallbacks are no longer embedded as landscape artwork

The audio download flow remains the same; this PR only changes how cover art is selected and processed.

## Related Issue
N/A. This change addresses incorrect landscape cover art being embedded for some downloads.

## Motivation and Context
The previous cover-art path relied too heavily on YouTube video thumbnails, which are a poor source for album artwork because they are commonly 16:9 and may not represent the actual release cover.

The goal of this change is to improve cover-art accuracy and consistency without reintroducing Spotify as a metadata dependency. By using music-oriented artwork sources first and keeping a square-processing fallback at the embedding stage, downloaded files are much more likely to receive correct-looking cover art.

## How Has This Been Tested?
Tested locally in the project virtual environment.

Focused tests were added/updated for:
- YouTube Music album-art resolution
- MusicBrainz/Cover Art Archive fallback resolution
- square cover processing before embedding

Command run:
```bash
./.venv/bin/pytest tests/providers/audio/test_ytmusic.py::test_ytm_get_cover_url_prefers_album_art tests/providers/audio/test_ytmusic.py::test_ytm_get_cover_url_searches_song_results tests/utils/test_cover_processing.py tests/utils/test_downloader.py --noconftest -q

Result:

• 6 tests passed

Additional verification:

• python -m py_compile passed for the modified modules

Note:

• I am not marking the full suite as passed because there is an unrelated existing test bootstrap failure in tests/conftest.py caused by the current Spotify stub/init mismatch.

Screenshots (if appropriate)

Not applicable. This change affects embedded file metadata/artwork rather than a UI surface.

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the CONTRIBUTING document
• I have added tests to cover my changes
• All new and existing tests passed

[CaptSolo]

Thank you for contributing to this project!
It might take me a bit before I get to review the PR.

Do you happen to know if it is possible to make spotdl retrieve just the album art, without having to download the tracks again?

[BernardMaacaron]

Hi! A pleasure regarding the contribution. I had such a nice setup with spotdl and your fix saved it so I'm the one to thank you.

I'll give it a look. I would assume if not that we can make use of the sync command and create a flag such as --retrieve-cover. I'll need some time to take a look as well.

[BernardMaacaron]

@CaptSolo I checked and the feature to add covers did not exist before so I added it. I also had covers already downloaded so to test it out I also implemented the removal option.

command is spotdl cover "file name or directory" with the --remove flag for removal.

I have to admit I got AI to do most of the work this time but it should be working fine. Let me know if that's okay.
Cheers