Fill total_tracks when Spotify strips it from the playlist object

[jonico]

Rescoped. This originally also changed get_playlist_tracks, which duplicated #17 / #18. That part is removed — see the note at the bottom.

Problem

get_playlist_info and playlist_resource both report total_tracks: null, even for a 65-track playlist.

Both ask for the count via playlist(fields="id,name,description,owner,public,tracks.total"), and a restricted app doesn't get that field back. Requesting it on its own makes that obvious:

sp.playlist(pid, fields="tracks.total")  -> {}
sp.playlist(pid)["tracks"]["total"]      -> None
sp._get(f"playlists/{pid}/items", limit=1, offset=0)["total"] -> 65   # correct

The rest of the fields list comes through fine — it's only tracks.total that's stripped.

Fix

Read the count off a one-item page of the items endpoint when the playlist object withholds it.

• A reported count is trusted as-is, so the extra request only happens when the field is genuinely missing — legacy apps pay nothing.
• Both call sites go through one helper, so they can't drift apart.

Testing

• ruff check, ruff format --check, mypy src/, bandit -r src/ all clean
• pytest: 171 passed (2 new — one per call site — plus an assertion that a reported count causes no extra lookup)
• Live-verified on a 65-track playlist, which is where the offline suite is blind:

get_playlist_info total_tracks: 65
playlist_resource total_tracks: 65

Both previously returned null.

Overlap with #18

I opened this before spotting #17 and #18. #18 fixes the same stripped field for get_playlist_tracks' pagination total, and does it the same way. To avoid competing with it:

• get_playlist_tracks is left untouched here — fix: read playlist entries from the "item" key, honor limit by rows #18 owns that call site.
• Only get_playlist_info and playlist_resource are changed, which fix: read playlist entries from the "item" key, honor limit by rows #18 doesn't touch, so they'd still report null after it merges.

There's a small cosmetic redundancy if both land: #18 reads the total inline, this adds a spotify_api.playlist_total() helper. Happy to rebase on top of #18 and have get_playlist_tracks use the helper too, if you'd prefer one source for it — just say which order you want them in.

get_user_playlists is deliberately left alone: filling counts there would mean one request per playlist on a list endpoint.

Note

No CHANGELOG.md entry deliberately — I have sibling fixes open (#19, #20) and they'd all conflict on the same lines. Happy to add one to whichever lands first.