sync_tidal_want_list passes an empty existing-ID set — every Tidal favorite is re-added on every sync

[forkwright]

Finding

ScrobbleClient::sync_tidal_want_list calls tidal::wantlist::sync_want_list with &HashSet::new() for the existing_tidal_ids argument. sync_want_list uses that set to diff the live Tidal favorites against the already-known want list. With an always-empty set, every favorite is classified as new on every invocation: the call returns all favorites as new MediaIds and emits a TidalWantListSynced event listing all favorites as additions.

Evidence

crates/syndesmos/src/lib.rs:113: &HashSet::new(), — a freshly constructed empty set is passed where the persisted ID set belongs. The sync_want_list signature (wantlist.rs:23) takes existing_tidal_ids: &HashSet<TidalId> precisely so the caller can supply current state.

Why this matters

Each sync reports the entire favorites list as newly added, so duplicate want-list rows accumulate in the store over time and TidalWantListSynced fires with redundant MediaIds every cycle. Downstream acquisition/download consumers re-acquire already-owned items repeatedly, wasting work and generating outbound requests proportional to favorite count on every run.

Desired correction

Load the current set of Tidal IDs from the apotheke store before calling sync_want_list and pass it as existing_tidal_ids. The query should return a HashSet<TidalId> of every want-list entry with a non-null tidal_id.
Done when: a second sync with no new favorites returns an empty vec and emits no TidalWantListSynced event.