provider art: a duplicate MusicBrainz entry is not a namesake

TheAudioDB records are held to a cross-provider identity test because a shared
name is not evidence -- namesakes are the bug it protects against. But it
demanded that TheAudioDB's MBID EQUAL the MB artist Deezer links to, and treated
any other id as a different act.

MusicBrainz carries duplicate entries for the same artist more often than that
assumes. Roosevelt has two -- 84825fb6 and d7eecee2, both "Roosevelt", Person,
DE, "German producer & DJ from Cologne". Deezer links the first, TheAudioDB
references the second, so his logo was discarded as belonging to someone else.

The rescue keeps names untrusted, which is the entire point of the gate: when
the ids disagree it asks whether TheAudioDB's OWN MusicBrainz entry links back
to the Deezer artist being resolved. d7eecee2 lists
https://www.deezer.com/artist/85901 among its url relations -- two MB entries
pointing at one Deezer id are the same act whatever their ids say. It only runs
when the cheap checks fail and it rides the shared cached artist lookup, so the
hot path is unchanged.

A linked MBID still outranks TheAudioDB's own strDeezerID, which can be stale
(`linked_mbid_outranks_stale_audiodb_deezer_id` covers that and still passes) --
the doc comment's "either ... or" describes a precedence the code deliberately
does not have.

Manifest recipe bumped to v5, or artists cached under v4 keep serving the
logo-less result this build would now fill. Safe now that a stale-recipe
manifest survives as a floor rather than being deleted on read.

Roosevelt: 0 logos -> 1 (his TheAudioDB logo). Verified unchanged: Fishmans 5,
King Gizzard 7, Wednesday 4, Pond 1, Ross from Friends 1, Camping in Alaska 0
(genuinely has none).

src-tauri/src/commands.rs

@@ -761,7 +761,12 @@ const ARTIST_HERO_CACHE_MAX_ENTRY_BYTES: u64 = 41 * 1024 * 1024;
 // whenever hero *selection* changes, not merely its rendering. Keeping the same
 // file path is safe: a recipe mismatch forces a fresh lookup and the successful
 // result atomically replaces the stale manifest.
-const ARTIST_ART_MANIFEST_RECIPE: &str = "artist-art-tier-v4-wide-only";
+// v5: TheAudioDB records referencing a DUPLICATE MusicBrainz entry for the same
+// artist are no longer rejected as namesakes, so artists cached under v4 are
+// holding a logo-less manifest this build would now fill. Safe to bump: a
+// stale-recipe manifest is kept as a floor and only replaced by a better
+// lookup, so nobody goes blank while the new one resolves.
+const ARTIST_ART_MANIFEST_RECIPE: &str = "artist-art-tier-v5-mb-duplicate-identity";
 // A resolved hero is expensive to find and does not go stale the way metadata
 // does -- a press photo is still the artist's press photo a month later. The
 // old 24h expiry meant every artist was re-discovered daily through a tier that