Ingest push: populate identity signals (ISRC / MusicBrainz / Spotify / Genius)

[Salem874]

Include ISRC / MusicBrainz recording MBID / Spotify track / Genius id in the lyrics-ingest payload so iHymns can fill tblSongIdentityMap (recording identity) and match on strong keys instead of fuzzy titles. Consumes iHymns identity-map schema (iHymns epic #1066). Depends on the iHymns ingest endpoint accepting the fields.

[Salem874]

Status check (2026-06-15)

Same dependency chain as #908: this depends on #907's lyrics-ingest client existing in MeedyaDL (the parent integration; still OPEN) and on the iHymns ingest endpoint accepting the new identity fields.

The identity signals themselves are mostly already populated by MeedyaDL's existing enrichment pipeline:

• ISRC — fetched per-track via the Apple Music API into TrackMetadata.isrc (apple_music_api.rs:211).
• MusicBrainz recording ID — populated when acoustid_enabled + AcoustID lookup succeeds, then the recording ID is reachable via the 3-tier MB lookup in musicbrainz_service.rs (per CLAUDE.md).
• Spotify / Genius URLs — sourced from MusicBrainzRecording.external_urls when musicbrainz_lookup is enabled (per CLAUDE.md "MusicBrainz lookup" feature description).

In other words, the data is already on disk per-track — the missing piece is the client that aggregates it into a payload and POSTs it, which is #907.

Recommendation

Same as #908 — roll this into #907 rather than standalone. Building the identity-signal extraction inside lyrics_ingest_client.rs::build_payload(track, lyrics, metadata) from the start is cheaper than retrofitting a partially-shipped client.

If you'd like me to start #907 with #908 + #909 baked in (one focused PR introducing the client + idempotency contract + identity signals together), say the word — that's the cleanest path. Otherwise this issue stays parked behind #907.