fix: shared MB rate limiter prevents search/indexer 429 collisions

Previously, the MusicBrainzClient had no proactive rate limiter —
it relied on the musicbrainzws2 library's retry-on-429 backoff.
When the background indexer was resolving artist images (hitting MB
at 1.5 req/sec) and a user search fired 3+ concurrent MB calls,
the combined burst triggered 429s with cascading retries up to 60s.

Now a single shared RateLimiter (1 req/sec) gates all MB API calls:
- MusicBrainzClient search/lookup/browse methods
- ArtistImageProvider fetchMBRels (was on a separate 1.5 req/sec limiter)

The limiter serializes access proactively, preventing 429s entirely.
The musicbrainzws2 retry logic remains as a safety net.

Also split the old shared limiter into separate lbLimiter (for
ListenBrainz + CoverArt) and mbLimiter (for MusicBrainz) so the
two APIs don't block each other.

frontend/wailsjs/go/explore/Service.js

@@ -42,6 +42,10 @@ export function GetThumbnails(arg1) {
   return window['go']['explore']['Service']['GetThumbnails'](arg1);
 }
 
+export function IndexNewArtists() {
+  return window['go']['explore']['Service']['IndexNewArtists']();
+}
+
 export function InvalidateIndexDiscographies() {
   return window['go']['explore']['Service']['InvalidateIndexDiscographies']();
 }