fix(portals): clear a playlist's pins by playlist, not by key list

Restoring over a playlist reused the keyed clear, which caps its input at
MAX_KEYS_PER_LOOKUP to bound an IN clause. A playlist with more than eight
pinned movies therefore kept the surplus while the call still reported
success, and the restore then wrote the archive's pins on top — leaving the
union of two states, which is neither the one the user asked for.

Clearing is now a dedicated delete-by-playlist operation with no key list to
truncate, and it refuses a blank playlist id rather than deleting everything.
A failure fails the entry instead of being swallowed: `listForPlaylist`
returns `[]` on error and `clear` returns `false`, so ignoring the result made
a failed read indistinguishable from "there was nothing to clear".

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

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

@@ -909,6 +909,10 @@ export interface ElectronBridgeApi {
     dbGetVodSourcePin: (matchKeys: string[]) => Promise<VodSourcePin | null>;
     /** Every pin pointing at this playlist — used by playlist backup. */
     dbListVodSourcePins: (playlistId: string) => Promise<VodSourcePin[]>;
+    /** Bulk clear: not keyed, so no `MAX_KEYS_PER_LOOKUP` truncation. */
+    dbClearVodSourcePinsForPlaylist: (
+        playlistId: string
+    ) => Promise<ElectronBridgeResult>;
     /** `retireKeys` are removed in the SAME transaction as the write. */
     dbSetVodSourcePin: (
         pin: VodSourcePin,