fix(spotify): back off status polling and handle 429 responses

[postigodev]

Summary

The Spotify page polls status every 2.5 seconds while focused. Each status refresh fetches Spotify devices and playback state, so simply leaving the page open generates a steady stream of API calls.

The poller also intentionally swallows errors and retries again on the next interval, which is especially unfriendly to rate-limit responses.

Expected outcome

Make Spotify status refresh less aggressive and rate-limit aware without making the page feel stale.

Acceptance criteria

• increase or adapt the polling interval so passive page viewing does not generate excessive API traffic
• preserve active-view-only polling and the existing no-duplicate-interval guard
• detect Spotify 429/rate-limit responses where available
• respect Retry-After rather than retrying every normal poll interval
• avoid surfacing repeated rate-limit failures as noisy activity entries
• keep explicit user-triggered refreshes responsive
• add focused tests around any pure backoff/rate-limit decision logic introduced

Possible directions

• use a slower steady-state interval and refresh immediately after user actions
• pause/back off after failures and resume after the retry window
• avoid fetching device discovery more often than necessary if playback state can be refreshed independently

Likely files

• apps/tauri/src/main.ts
• crates/core/src/spotify/mod.rs
• potentially a new Spotify controller/helper as part of Modularize Spotify page controller logic #10