library: parallelize standby media fetching and add search-position tiebreak

[LWWZH]

Closes #902

Changes

1. Parallel media fetching in a_list_song_standby_v2

The standby search's second phase (fetching media URLs for qualified candidates) was serial: each candidate was tried one-by-one with await inside a for loop. This is now parallel — all candidates' media are fetched concurrently via asyncio.gather, then results are collected in score-sorted order.

Candidates are already bounded by max_per_source=2 per provider, so the total number of concurrent requests stays manageable.

2. Search-result position as tiebreaker

When two candidates have the same match score, the one that appears earlier in its provider's search results is now preferred. This leverages the platform's own ranking as a relevance signal, since providers typically return the most relevant results first.

The sort key is (-score, result_position) — highest score first, then lowest position first.

Testing

Two new tests in tests/library/test_library.py:

• test_library_a_list_song_standby_v2_fetches_media_in_parallel — verifies multiple providers' candidates get media fetched concurrently
• test_library_a_list_song_standby_v2_uses_search_position_as_tiebreak — verifies same-score candidates are ordered by their position in provider search results

All 13 library/standby tests pass.

[cosven]

这里面有个问题，假设总共3个source，每个 source 都匹配到2个候选歌曲。本来的排序是
(a1,9)
(a2, 8)
(b1,9)
(b2,7)
(c1, 8)
(c2, 6)

那么以前的逻辑，会按照分数去看是否有合适的播放资源，也就是先看 a1 和 b1 是否有可播放资源。然后再看其它的。

现在这样改了之后，相当于不会关注它的分数了。

[LWWZH]

@cosven
已修改，按分数分组并行，高分优先处理。