Fix: Cross-plugin fallback on AutoPlay-Mix #337

[AbyssalSoda]

Relevant to the second portion of Bug: #337 wherein the application correctly resolves for a missing plugin, but fails to initiate the AutoPlay-Mix request.

• Added resolvedPluginId to ResolvedMediaSource so the player knows which plugin actually served the stream, not just which plugin is embedded in the track's media ID.
• RelatedSongsManager now uses the effective plugin for 'radio' instead of blindly parsing the plugin ID from the track ID which may point to a disabled plugin). It now prefers the caller-supplied resolved plugin ID.

---

• Comments left for review in the format demonstrated within the code.
• Some areas given minor reformatting to match the rest of your code.

[HemantKArya]

lot of code is changed I hope you are testing the code properly and writing the code clear and with compact explanation. current code changes seem a bit vague or direct changes without understanding I hope you can provide some explanations or any refactored commit for it.

[AbyssalSoda]

Essentially the goal here was to make the recovery persistent by tracking the redirect request from the embedded "Source plugin" (the original resolver the track was from) to the "Resolved plugin" (the resolver the request was redirected to). To do this I created resolvedPluginId and cached it via lastResolvedPluginId, so when tryAutoResolveUnavailableTrack returns a replacement track, the resolver reads the replacement's embedded plugin ID and surfaces it as resolvedPluginId. It then carries that fallback plugin id through to the cache before passing it to the AutoPlay-Mix service in RelatedSongsManager. This bypasses the "source" plugin embedded in the metadata when the original source plugin is unavailable for subsequent contextual requests.

Regarding error handling, as this can be a big point of contention, registerAttempt was removed since the fallback logic in resolveTrackWithAutoReplacement resolves the redirect before the error handler is involved. The message format "Plugin Not Found" followed by "Playing a fallback source for (song/track name)" remains unchanged and displays as intended. That said, errorSub will be reverted and retested as I don't actually remember why I modified that (might have been an automated suggestion). I know NetworkError change was, but its also slightly more appropriate, as errors here aren't specific to dropped connections.

If you want to test what this aims to fix: Find a song via the Youtube Video resolver, like/favorite it, then disable the Youtube Video resolver plugin. Go back to your liked playlists and play the song, it will recover it as intended (native behavior). However, if you now go back to the same song again and press "AutoPlay-Mix" it will recover the song, but fail to generate a playlist as requested.

Important Note: If we disable all plugins, a runaway error message occurs on long playlists "Song Format unsupported or corrupted. 1/3" It will try this 3 times before moving onto the next song and trying again for a few more songs. This is native behavior, and I left this unchanged. The presence of registerAttempt did not have an impact on here, and if it should have, I can reintroduce and reexamine.