feat(source): wire My QBZ through the seam, and land the owner's container rules

Stage 2. The measured win: opening a 34-item collection now costs **2** library.db
opens instead of 23-34 — the local source owns a pooled handle and hands out no
guard, only `with(|db| ...)`, so a `!Send` `&LibraryDatabase` cannot cross an
await either. Bug 1 from the seam design is dead by construction, not by care.

The owner's rules, decided today, now live in one place instead of eight:
- **Collection** takes albums, singles and EPs from ANY source — qobuz, folders,
  Plex, and whatever is added next. **Mixtape** takes albums, playlists and
  tracks. This was a single boolean (`restrict_to_mixtape`) that could express
  neither release types nor "collections accept local".
- An unsupported combination must never be VISIBLE: the picker stops offering
  the impossible action, and the error stays a log-only safety net. Owner: "el
  bloqueo no debería ser visible nunca, más bien esto hay que ajustarlo en la UI".
- **Ephemeral honours its name** — playable, queueable, and offerable to nothing
  else.
- A row's source comes from the ROW. Eight QML sites built the add-to-mixtape
  payload with `"source": "qobuz"` written as a literal, so a Plex or local
  track was stored as Qobuz and afterwards could not play at all: the app asked
  the Qobuz API for an id that never existed there.

`QobuzSource` reads the client through a lens on every call instead of holding a
clone. That is not style: `qbz-core` REPLACES its client (core.rs:346 and :384,
both on paths that run before `set_session`), so a cached clone goes stale and
fails silently — the hazard the crate's own doc comment described.

The lens is installed in `on_boot`, first of everything, and finding out why is
the lesson of this commit. The gate was green — build, 142 tests, both QML
audits, a clean offscreen smoke — and the feature was visibly broken: every
Qobuz row showed "No results found", an empty Quality cell and a wrong "SINGLE"
type, while the Plex rows resolved fine. The registry is a OnceLock, so whoever
touches it first BUILDS it, and one built without the lens leaves Qobuz
permanently detached. Only driving the real app surfaced it; the crate's error
string named the cause exactly, which is the one thing that made it a ten-minute
fix instead of an afternoon.

cc

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

@@ -647,6 +647,16 @@ Rectangle {
                     onRemoveRequested: QbzBridge.playlistRemoveTrack(item.playlistTrackId)
                     // MyQBZ "Add to mixtape" — the HOST builds the AddItem
                     // array (TrackRow does not know itemType/source).
+                    //
+                    // SOURCE: `PlaylistTrackRow` (playlist_qt.rs:47-78) has no
+                    // source field because this whole view has one source —
+                    // LOCAL playlists are out of scope everywhere in it
+                    // (playlist_qt.rs:23-25), the document is mapped from
+                    // Qobuz `Track` values, and `playlistTrackId` is the
+                    // Qobuz membership row id. `item.id` is a Qobuz catalog
+                    // id by construction of the view, not by assumption here.
+                    // If local playlists are ever ported, the row must start
+                    // carrying its source and this must read it.
                     onMixtapeRequested: QbzMyQbzAdd.open(JSON.stringify([{
                         "itemType": "track", "source": "qobuz",
                         "sourceItemId": item.id, "title": item.title || "",