feat(portals): carry VOD source pins through playlist backup

The new pins table was invisible to backup: exporting a playlist and
re-importing it on a new machine silently dropped every "main source" choice,
with nothing in the archive to say the choice had ever been made.

Pins now ride along under the playlist they point AT — carrying them anywhere
else would restore a preference for a portal the archive never contained.
`matchKey` names the film rather than the portal, so it survives untouched and
only the playlist id is remapped to the imported copy.

`sourcePins` is the one optional collection in the Xtream user state: archives
written before multi-source existed simply do not have it, so its absence is
age rather than damage. Only a wrong type is rejected, and pins without a
usable match key or content id are dropped, since writing one would occupy the
unique key of a film it does not describe.

Adds `DB_LIST_VOD_SOURCE_PINS` through the usual six seams (operation, worker
case, event, preload, bridge contract, service).

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

docs/architecture/playlist-backup-restore.md

@@ -162,12 +162,23 @@ worker IPC boundary in the snake_case wire shape declared by
 `XCategoryFromDb`/`XtreamCategoryFromDb`; the category operations project
 their Drizzle rows explicitly to keep that contract true.
 
+`sourcePins` (VOD multi-source) is the one **optional** collection: archives
+written before multi-source existed simply do not have it, so its absence is
+age rather than damage and only a wrong type is rejected. A pin is carried
+under the playlist it points AT — exporting it anywhere else would restore a
+preference for a portal the archive never contained. Its `matchKey` identifies
+the film rather than the portal, so it survives untouched; only the playlist id
+is remapped to the imported copy. Pins whose match key or content id is
+unusable are dropped, since writing one would occupy the unique key of a film
+it does not describe.
+
 Electron restore behavior:
 
 1. Category import reads pending hidden-category state while saving categories.
 2. After content import, favorites/recent state is restored by typed
    `{ contentType, xtreamId }` matching.
 3. Playback positions are cleared and re-applied from backup state.
+4. VOD source pins are re-applied against the IMPORTED playlist id.
 
 For existing Xtream playlists with a fully populated offline cache, backup
 import applies the restore immediately. Otherwise the typed restore payload is

docs/architecture/vod-multi-source.md

@@ -478,6 +478,14 @@ Two things read it, and they must agree: the "Playing from" caption, and the
 source row's badge — which reads `Current` when a source is merely selected and
 `Playing` once one really is.
 
+## Backup
+
+Pins ride along with playlist backup, under the playlist they point at, as the
+optional `sourcePins` collection. See
+`docs/architecture/playlist-backup-restore.md` for the remapping and
+sanitizing rules — the short version is that `matchKey` names the film and
+survives as-is, while the playlist id becomes the imported copy's.
+
 ## Which engines can fail over
 
 Only the built-in web players (HTML5, Video.js, ArtPlayer) raise the playback