fix(portals): keep a pin readable under every identity of its film

Two defects in the pin/position subsystem, both reported in review.

A pin was stored under the movie's most-trusted key alone and its other
keys retired. But a movie's identity GROWS: the film keyed `tmdb:438631`
today was `title:dune:2021` before enrichment, and reopening it cold asks
for the poorer key first. The preference was therefore ignored until
enrichment landed — and permanently when enrichment is off or never
answers. The decision is now written under every key in `write` (never
the yearless form, which every remake shares), one upsert per key plus
the leftover retirement in the same transaction. `setVodSourcePin` also
reports failure for a pin with no usable key instead of claiming a write
it never made.

The primary button asked whether the pinned copy's position had loaded
by testing presence rather than identity, so re-pinning left it wearing
the previous copy's timecode until the new lookup returned.

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

libs/shared/interfaces/src/lib/electron-api.interface.ts

@@ -913,10 +913,15 @@ export interface ElectronBridgeApi {
     dbClearVodSourcePinsForPlaylist: (
         playlistId: string
     ) => Promise<ElectronBridgeResult>;
-    /** `retireKeys` are removed in the SAME transaction as the write. */
+    /**
+     * `aliasKeys` receive the same pin, and `retireKeys` are removed, all in
+     * the SAME transaction as the write. Aliases keep a pin readable under the
+     * poorer key forms the movie had before enrichment.
+     */
     dbSetVodSourcePin: (
         pin: VodSourcePin,
-        retireKeys?: string[]
+        retireKeys?: string[],
+        aliasKeys?: string[]
     ) => Promise<ElectronBridgeResult>;
     dbClearVodSourcePin: (
         matchKeys: string[]