fix: decode per-row like status for radio queues

[WGlegola]

Problem

In the queue side panel ("Up Next"), a track's like/thumbs-up indicator depended on how much of the user's Liked Music playlist had loaded in the background. Playing from the main Search bar builds a radio "Up Next", and as Liked Music paginated in, more queue rows would progressively light up as liked — because the like status wasn't attached to the queued songs, only resolved from a global cache that Liked Music seeds incrementally.

Root cause

RadioQueueParser.parseSongs built each queued Song with likeStatus == nil, dropping the likeStatus that the same playlistPanelVideoRenderer.menu carries (and that SongMetadataParser already decodes for the seed track). The queue row then resolved its thumb solely from SongLikeStatusManager's cache (cache[videoId] ?? song.likeStatus), which is seeded batch-by-batch by Liked Music pagination — so rows lit up as more batches loaded.

Fix

• RadioQueueParser now decodes each row's like status from its own menu (reusing SongMetadataParser.parseMenuData) and sets Song.likeStatus, so every queued row carries an authoritative per-track status independent of cache-seeding timing. Library/feedback fields are intentionally left unset to avoid suppressing the single-track metadata fetch and queue enrichment.
• SongMetadataParser.parseMenuData is made robust to a missing overflow-items menu, so likeStatus (which lives in topLevelButtons) is never dropped when a menu lacks items.
• The cache remains checked first, so a live rating change (from the queue row, now-playing, or Liked Music seeding) still overrides the parsed value.

Tests

Added RadioQueueParserTests covering LIKE/DISLIKE/INDIFFERENT decode, the nil-when-no-menu guard, the wrapped-renderer path, and the continuation path. Full non-UI suite passes; swiftlint --strict and swiftformat clean.