fix(player): bigger retry budget + return value for /play-playlist

The previous fix for "播放全部 没有反应" hooked into playNext but had
two problems:

1. Used !!queue.current() to detect success, which is always true
   after queue.next() advanced — so the response message would lie
   about playback starting even when all retries failed.

2. The default 3-retry budget is sized for "next song couldn't
   resolve, skip it" cases. User-initiated playlist plays commonly
   hit long contiguous runs of QQ 104003 songs in collected playlists
   (entire ACG/古风 packs can be uniformly unstreamable in some
   regions), so 3-4 attempts wasn't enough.

Make playNext return whether a song actually started, and accept a
maxRetries parameter. /play-playlist now uses 20 retries — high
enough to clear typical unplayable runs, bounded enough that fully
unstreamable playlists still surface a clear "none were playable"
message rather than hanging.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/web/api/player.ts

@@ -266,13 +266,13 @@ export function createPlayerRouter(
       }
 
       // If the first picked song can't resolve (e.g., QQ song with no
-      // streaming entitlement → result 104003), fall back to the same
-      // retry-skip behavior playNext uses for trackEnd auto-advance.
-      // Otherwise the bot would sit silently on a dead song.
+      // streaming entitlement → result 104003), fall back to playNext's
+      // retry-skip behavior. Use a higher retry budget than the default
+      // trackEnd auto-advance because user-initiated playlist plays
+      // commonly have long contiguous runs of unplayable songs.
       let started = first ? await bot.resolveAndPlay(first) : false;
       if (first && !started) {
-        await bot.playNext();
-        started = !!queue.current();
+        started = await bot.playNext(20);
       }
 
       const playing = queue.current();