fix(player): separate selection from audio state

docs/audio-switching-notes.md

@@ -4,22 +4,22 @@ Referencia interna para futuras correcciones del reproductor de PluriWave. Este
 
 ## Hallazgos útiles
 
-- `AudioPlayer.play()` **no debe esperarse como si fuera “arrancar y terminar”** en un stream de radio en vivo. Según la documentación de `just_audio`, el `Future` de `play()` completa cuando la reproducción termina, se pausa o se detiene. En una radio en vivo puede quedar vivo hasta que otra acción lo interrumpa.
-- Para streams en vivo, la UI debe depender de `playerStateStream`: `loading`/`buffering` para spinner, `ready + playing` para estado en directo.
-- El ejemplo de radio de `just_audio` configura sesión de audio y escucha errores de playback. Conviene tratar el cambio de emisora como una operación transaccional: parar fuente anterior, asignar fuente nueva y arrancar sin bloquear el flujo principal.
-- En `audio_service`, si se cambia de fuente desde `playMediaItem`, hay que evitar que errores tardíos de la fuente anterior limpien la emisora nueva. Es una carrera típica cuando se hace `stop()` y enseguida se carga otro stream.
+- `AudioPlayer.play()` completa cuando la reproducción termina, se pausa o se detiene. En radio en vivo no representa simplemente “ya empezó a sonar”.
+- Las versiones antiguas de PluriWave que sí cambiaban de emisora usaban el flujo simple de `audio_service` + `just_audio`: `stop() -> setUrl() -> play()` dentro de `playMediaItem`.
+- La regresión apareció cuando mezclamos dos responsabilidades: usar `handler.emisoraActual` como estado técnico de audio y también como estado visual inmediato para mostrar el mini reproductor.
+- En la versión vieja, el audio podía cambiar correctamente aunque `emisoraActual` no se usara como “selección visual inmediata”. Para arreglar el primer render del mini reproductor sin romper audio, conviene separar ambos conceptos.
 
 ## Decisión aplicada en PluriWave
 
-- Mantener `setUrl(...)` porque era la ruta que conectaba correctamente la primera emisora en esta app.
-- Serializar cambios de emisora con una cola interna para que no se solapen `stop/setUrl/play`.
-- Usar una revisión incremental para que solo la última solicitud pueda actualizar estado/errores.
-- Ejecutar `play()` sin `await`, porque en radios en vivo su `Future` no representa “ya arrancó”, sino “terminó/pausó/detuvo”.
-- Proteger `EstadoRadio.reproducir` con revisión para que una reproducción vieja que termine tarde no aplique presets/clicks encima de la emisora nueva.
+- Restaurar el flujo histórico del handler: `stop -> setUrl -> play`.
+- Mantener la selección visual inmediata en `EstadoRadio` mediante una emisora seleccionada propia, separada del `emisoraActual` interno del handler.
+- No usar `setAudioSource(..., preload: false)` como reemplazo de `setUrl(...)`: en esta app rompió incluso la primera conexión.
+- Proteger `EstadoRadio.reproducir` con revisión para que una operación vieja no aplique presets/clicks encima de una nueva.
 
-## Intento descartado
+## Intentos descartados
 
-- Se probó `setAudioSource(..., preload: false)` siguiendo una interpretación más transaccional del API, pero en PluriWave rompió incluso la primera conexión. Queda descartado salvo que se acompañe de logs nativos que justifiquen retomarlo.
+- `setAudioSource(..., preload: false)`: teóricamente razonable, pero en PluriWave rompió la primera conexión.
+- Hacer que el handler publique `emisoraActual` antes de que el flujo histórico de audio avance: arregla el mini reproductor, pero cambia la semántica que tenían las versiones viejas.
 
 ## Fuentes consultadas