Fetch the next track while the current one plays

[Isma-L154]

Closes #27

The problem

The player only started resolving the next track after the current one ended, so every transition stalled on yt-dlp — 3 to 8 seconds, every time.

Measured on the production host, playing a YouTube URL:

1. resolve metadata     3.48s     media.search()
2. first byte of audio  3.61s     spawn_stream()
   TOTAL                 7.08s

Two separate extractions of the same video: the command resolves metadata for the "Now Playing" embed, then the player loop launches a new yt-dlp that redoes the whole thing to download.

That work cannot be made cheaper. I tested the obvious idea — skipping format processing, since spawn_stream resolves formats again anyway:

	Time
Full extraction	2.70s
process=False	2.83s

No difference. The cost is the round trip to YouTube, not local work. So this PR moves it off the critical path instead of trying to shrink it.

The result

=== SIN prefetch: lo que pasa hoy al cambiar de cancion ===
  el usuario espera: 7.13s

=== CON prefetch: el stream ya estaba listo ===
  el usuario espera: 0.000s

Timing is deliberate

A prefetched yt-dlp sits blocked on a full pipe until we consume it, and YouTube drops connections that idle too long — fetching at the top of a six-minute track would leave a dead stream by the time it was wanted.

So fetching starts PREFETCH_LEAD_SECONDS (30s) before the current track ends. Short tracks and live streams, which have no useful end to count back from, fetch immediately.

The risky part is the discard, not the fetch

A prefetched stream is a live yt-dlp process. One that is fetched and never claimed is precisely the leak that produced a 19-day zombie before #6. Most of the new tests are about that.

Situation	Behaviour
The next track is what we prefetched	hand the stream over
Skip / remove / shuffle / previous changed it	close it, then spawn fresh
destroy() with a ready prefetch	close it
destroy() with a fetch in flight	cancel the task, close on arrival
Track-loop mode	never prefetch — the next track is the current one

Matching is by identity, not URL. Two queue entries for the same song are different tracks — one has been claimed, the other has not. Matching on URL would hand the same stream to both. test_matching_is_by_identity_not_by_url pins it.

Verification

275 passed, three consecutive runs, 17 new. The new tests use an async fixture so get_running_loop sees the loop pytest-asyncio actually runs the test on, and they wait on run_in_executor completions rather than assuming a few event-loop yields are enough — the first draft asserted too early and failed for that reason.

Covered: when the delay fires for long, short and live tracks; that the front of the queue is what gets fetched; that a second call does not fetch twice; every discard path above; and that a track ending early (skip, stop, effect change) returns from the wait promptly instead of sitting on its timeout.