Fix[LB-1947]: Track listen count stuck

[Swaim-Sahay]

Description

This PR fixes an issue where the global track and album listen counts were actively getting stuck and not updating and also corrects a bug computing release group popularity.

Ticket: LB-1947

Problem

Our background system caches a large chunk of listen data so it doesn't have to recalculate it from scratch every day. The problem was that when fresh listen data was imported, the system didn't realize it had been updated so it kept using the old frozen cache forever. Because of this the final listen numbers shown to users never went up. There was also a small bug where the wrong math was being used for release group listen counts.

Solution

Taught the caching system to remember exactly where it got its data from. Now, if it notices that the main data location has changed it knows to throw away the old cache and build a new one. We also pointed the release group counts to the correct calculation.

Changes Made

1. listenbrainz_spark/schema.py: Added a dump_location field to keep track of where the data came from.
2. listenbrainz_spark/stats/incremental/incremental_stats_engine.py: Updated the system to check and save the dump_location so it can detect when new data arrives.
3. listenbrainz_spark/popularity/listens.py: Corrected the query used for calculating release group popularity.
4. listenbrainz_spark/popularity/mlhd.py: Minor update to keep the old code compatible with the new dump_location tracking.

AI Usage

• Received assistance with pinpointing the logical bug and writing out the fix.
• All code has been thoroughly reviewed, manually tested and fully understood prior to submission.