[tuner E/#657] badge coverage cue: stale async report can restore the previous song's ring

[byrongamatos]

Found in review of #657 (passive 'different tuning' badge cue).

P2. In static/v3/badges.js, _refreshCoverageCue() awaits api.coverageReport(songInfo) then unconditionally writes _lastCoverageReport and the DOM. The clear paths (song:loading, non-player screen:changed) are synchronous and don't invalidate an in-flight request, so a slow /api/settings fetch can restore the previous song's amber ring after the next song started loading / after navigating away. It self-corrects on the next song:ready, but shows a transient wrong cue.

Fix: a monotonic request token bumped on song:ready/song:loading/screen:changed; apply the awaited report only if the token still matches.

[byrongamatos]

Fixed via #683 (0013c9b), merged into feat/v3-tuner-coverage-badge (the tuner-E stack branch). Reaches main when the E-stack (#655→#656→#657) lands. (Auto-close didn't fire — the fix PR merged into a feature branch, not the default branch.)