fix(myqbz): stamp the cover when an item is added to a collection

`mixtape_collection_items.artwork_url` is a SNAPSHOT written once at add
time. The grid tile and the hero mosaic read that column and stop — only
the detail row has a backfill — so an item stored without a cover is
blank on those surfaces for the life of the row.

WHAT THE DATA SAID, against two hypotheses including mine. The owner
reported albums added "from Qobuz" arriving coverless, and the obvious
suspects were a narrow ImageSet read and the disco builder. Querying the
live library.db settled it: 8 of 35 rows have an empty artwork_url and
every one of them is `item_type='album' source='local'`, while every
Qobuz album row carries a url. So the confirmed gap is the LOCAL album
page's cassette button, which passed `artwork_url: None` outright — the
only call site in the app that could produce those rows. It now stamps
the album's own cover path, which is correct to store here: the mosaic
passes local paths through unrewritten, and that is what lets a
collection of local albums render with no network at all.

Also stamped, where the remote url was already in hand and only an empty
string was being sent: Search, Playlist, Library, Artist and Label track
rows. AlbumView takes the HEADER's url rather than the row's — album-view
track rows are published with an empty artUrl by construction
(album_qt.rs says so in the field's own doc), so the obvious edit there
would have been a no-op, and every track of an album shares its cover.

Four sites still send nothing and now SAY why in place: the three
now-playing bars and MixView have only a file:// cache path or no url at
all, and a cache path must never be stored — other machines read this
column. Those need a remote-url field on their documents first.

The `image.best()` widening in album_qt/bulk_tracks_qt rides along as
hygiene, not as the fix: `thumbnail.or(small)` was the outlier in a file
that reads every other cover through `best()`. An adversarial pass over
494 real ImageSets found ZERO albums lacking both fields, so it was not
what the owner hit — it is simply the read the rest of the file already
agreed on.

STILL OPEN: if the owner's two albums were Qobuz after all, their urls
ARE stored, and the symptom is on the render side — the mosaics have no
fallback where the detail row does.

cc

crates/qbz-qt/qml/views/AlbumView.qml

@@ -1370,7 +1370,12 @@ Rectangle {
                         onMixtapeRequested: QbzMyQbzAdd.open(JSON.stringify([{
                             "itemType": "track", "source": "qobuz",
                             "sourceItemId": item.id, "title": item.title || "",
-                            "subtitle": item.artist || "", "artworkUrl": "",
+                            "subtitle": item.artist || "",
+                            // The HEADER's url, not `item.artUrl`: album-view
+                            // track rows are published with an empty artUrl
+                            // (album_qt.rs:90 says so out loud), and every
+                            // track on an album shares the album cover anyway.
+                            "artworkUrl": (albumHeader && albumHeader.artUrl) || "",
                             "year": null, "trackCount": null
                         }]))
                     }