fix(spotify): profile identity from the session, not spclient (v1.1.0)

[volod-vana]

What

Spotify exports were stamped with a stranger's name and avatar ("Micael Widell") over the user's own account.

Root cause

The connector built spotify.profile from two sources: id/uri from the session-bound GraphQL me query (correct), but display_name/avatar/follower-counts from spclient.wg.spotify.com/user-profile-view/v3/profile/me. That spclient endpoint is not session-bound - called with a token that is not tied to a user it still returns 200 with uri: "spotify:user:me" and a fixed foreign profile. So the merged record carried the user's real id and real collected tracks, but someone else's name/photo/counts.

Reproducible with a fresh anonymous token (no login, no cookies) - every caller gets the same foreign profile:

curl -s https://spclient.wg.spotify.com/user-profile-view/v3/profile/me \
  -H "authorization: Bearer $TOKEN" -H "app-platform: WebPlayer"
# -> {"uri":"spotify:user:me","name":"Micael Widell", "followers_count":56, ...}

Fix

• Identity (id, display_name, uri) comes only from the session GraphQL profileAttributes.me.
• spclient is used strictly as enrichment (avatar + counts, not exposed by GraphQL) and only when its uri equals the resolved identity; the spotify:user:me sentinel is rejected.
• If the session profile cannot be resolved, the run fails clearly instead of importing a stranger.
• Version 1.0.0 to 1.1.0; connector-index regenerated.

Follow-up (separate)

Every user who already connected Spotify has a spotify.profile record with the wrong name/avatar in their PS - needs a re-collect or a one-off rewrite. Will file a ticket.

[github-actions]

Schema Health Check — Non-blocking inherited issues

44/50 scopes consistent | 6 inherited Gateway gap(s) | no new blocking issues in this PR