fix(lidarr): add an album as the looked-up resource with its artist nested (#5234)

Lidarr's POST /api/v1/album validates `artist` as a nested resource
(AlbumController: RuleFor(s => s.Artist).NotNull()), so the flat payload
we sent was refused with "'Artist' must not be empty" every time. The
album add has never worked against a real Lidarr; approved album and
track requests sat in the reconciler retrying every 5 minutes.

AddAlbum now does what Lidarr's own add-album UI does (getNewAlbum /
getNewArtist): look the album up by MBID (album/lookup?term=lidarr:<mbid>),
then POST that resource back with monitored + searchForNewAlbum. When
Lidarr doesn't have the artist yet, the nested artist gets the request's
quality/metadata profile and root folder, monitors this album only
(monitor "none" + albumsToMonitor, which AlbumMonitoredService prefers)
and no future releases. An artist Lidarr already has is left as it is.
An MBID Lidarr's metadata doesn't know is ErrNotFound with no POST.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

internal/lidarr/types.go

@@ -60,10 +60,10 @@ type AddArtistParams struct {
 	MonitorAll        bool // true => monitor="all"; false => "future"
 }
 
-// AddAlbumParams are the fields Lidarr requires on POST /api/v1/album.
-// MetadataProfileID is included for the case where Lidarr has to create
-// the parent artist on the fly (when adding an album by an artist not
-// yet in the library).
+// AddAlbumParams identify the album to add and carry the settings Lidarr
+// needs when it has to create the parent artist on the fly (an album by an
+// artist not yet in Lidarr). The artist fields are a fallback only: the
+// album lookup normally supplies the artist itself.
 type AddAlbumParams struct {
 	ForeignAlbumID    string
 	ForeignArtistID   string // Lidarr requires the artist's foreign id too