fix(xtream): preserve favorites across catalog refreshes

docs/architecture/sqlite-db-worker.md

@@ -656,6 +656,26 @@ is unavailable or the SQLite playlist migration has not completed.
 5. `DB_GET_GLOBAL_FAVORITES`
 6. `DB_GET_ALL_GLOBAL_FAVORITES`
 7. `DB_REORDER_GLOBAL_FAVORITES`
+8. `DB_RESTORE_XTREAM_FAVORITES`
+9. `DB_GET_FAVORITES_FOR_BACKUP`
+
+Xtream favorites survive catalog/category deletion through nullable `content_id`
+links and independent typed provider identities plus display snapshots. Reads
+return the durable `favorite_id`, nullable catalog IDs and `catalog_status`;
+remove accepts `{ favoriteId }` and reorder accepts `favorite_id` without a
+catalog row. Legacy content-ID callers resolve playlist/type/provider identity,
+including duplicate category rows. Import completion reconciles links and saved
+metadata; detail enrichment also updates the snapshot. Known identity conflicts
+remain unresolved. See [Xtream compatibility](./xtream-portal-compatibility.md#durable-electron-favorites).
+
+`DB_RESTORE_XTREAM_FAVORITES` materializes pending/backup snapshots without an
+online catalog. Inserts and their replay receipt share one synchronous worker
+transaction, so retry after removal does not resurrect an item. Explicit backup
+imports supply a fresh restore ID; legacy pending payloads use a canonical
+hash. `DB_DELETE_XTREAM_CONTENT` returns no canonical favorites to replay.
+`DB_GET_FAVORITES_FOR_BACKUP` deliberately includes locked/unresolved rows;
+ordinary UI reads preserve parental-lock filtering. A failed export read must
+propagate to the caller.
 
 ### Recently viewed