fix: handle Spotify API rename of 'track'/'tracks' keys to 'item'/'items'

[MojtabaTajik]

Problem

Spotify's Web API silently renamed keys in playlist response objects:

Old key	New key	Location
tracks	items	Playlist envelope (the dict wrapping track list + total)
track	item	Individual track entry within that list

This caused KeyError crashes on any call that reads playlist contents — get_playlist_tracks, parse_playlist, and parse_tracks all hard-coded the old key names.

Fix

Use a .get() fallback that accepts both key names so the code works regardless of which version the API returns:

# Before
playlist['tracks']['items']

# After
items_info = playlist.get('items') or playlist.get('tracks') or {}
items_info.get('items', [])

Same pattern applied consistently in:

• utils.parse_tracks — item['track'] → item.get('item') or item.get('track')
• utils.parse_playlist — track envelope + individual track + owner field access made safe
• spotify_api.get_playlist_tracks — top-level playlist dict access

Also adds the missing @utils.ensure_username decorator to get_current_user_playlists and filters None results from parse_playlist to avoid downstream errors on partial API responses.

Testing

Verified against a live Spotify account with 20+ playlists and 100–130 track playlists. All playlist listing, track fetching, add, and remove operations work correctly after this change.