verify_performer_references.py bypasses shared MusicBrainz client (no retry/backoff/cache)

[dprodger]

Summary

scripts/verify_performer_references.py makes its MusicBrainz calls by hand instead of using the shared, hardened client at backend/integrations/musicbrainz/client.py.

• verify_musicbrainz_reference() — raw self.session.get("https://musicbrainz.org/ws/2/artist/{mb_id}") + flat time.sleep(1.0) (verify_performer_references.py:152-161).
• search_musicbrainz() — same pattern (verify_performer_references.py:280-288).

Neither path has retry, exponential backoff, or caching. The shared MusicBrainzClient already provides all three — retry + exponential backoff on 503/429/connection errors (client.py:9,685-692).

Impact

In the default and --reftype musicbrainz modes, a transient MusicBrainz 503/429 (common — MB rate-limits aggressively) causes a verification to fail outright. Since the script removes references it judges invalid, a flaky MB response can lead to a valid musicbrainz_id being scored 0 and deleted. The bespoke calls also re-fetch every time (no caching), making bulk runs slower than necessary.

This is the same class of drift as the missing load_dotenv() and the loop-level sleep: the script predates / never adopted the shared infrastructure that the rest of the backend uses.

Proposal

• Replace the inline MusicBrainz HTTP calls in verify_performer_references.py with MusicBrainzClient (integrations/musicbrainz/client.py), reusing its retry/backoff/rate-limiting/caching.
• Audit other scripts under backend/scripts/ for the same hand-rolled MB pattern and migrate them too.

Acceptance criteria

• verify_performer_references.py uses MusicBrainzClient for all MusicBrainz lookups
• Transient MB errors are retried before a reference is judged invalid/removed
• No duplicated MB request/rate-limit logic remains in the script