fix(wear): confiabilidad de la transferencia de playlists — hallazgos de la primera prueba en hardware

[PonceGL]

Contexto

Primera corrida real en dispositivo de la Fase 1 completa: playlist de 6 canciones, teléfono S25 Ultra + reloj Galaxy Watch (SM_R920), audífonos Bluetooth conectados. Encontró 3 bugs reales, todos con causa raíz confirmada en el código (no especulación) — este PR los corrige.

Qué corrige

1. El watchdog de transferencia no cancelaba nada de verdad

armTransferWatchdog disparaba a los 120s de inactividad y solo actualizaba el mapa de estado (activeTransfers → FAILED, limpiaba pendingMetadata) — pero la corrutina que de verdad estaba leyendo el InputStream del ChannelClient seguía corriendo, sin enterarse. En una sola transferencia de 6 canciones esto pasó dos veces, de dos formas distintas:

• Una canción marcó "timed out" pero el loop de lectura siguió y terminó bien solo — falsa alarma, pero el watchdog se re-armaba en cada lectura restante, así que el mismo requestId podía disparar varias veces (vi 2, 3 y hasta 4 disparos sobre la misma transferencia).
• Peor: al disparar, se borraba pendingMetadata debajo del loop que seguía vivo — cuando por fin terminó de recibir bytes y quiso resolver su metadata para escribir el archivo, ya no la encontró (Transfer metadata missing), se borró el archivo temporal, y la canción se perdió de verdad a pesar de que todos los bytes habían llegado.

Corrección: el watchdog ahora cierra el InputStream real (rastreado por requestId) cuando dispara, lo que desbloquea el read() con un IOException y lo enruta por el mismo catch que ya maneja la limpieza — un solo camino consistente en vez de dos procesos independientes pisándose.

No es testeable en JVM tal cual está: el watchdog es un delay() real sin reloj inyectado, y la función relevante es privada. Verificado por revisión de código contra la secuencia exacta observada en hardware — necesita reverificarse en dispositivo (mismo escenario: audífonos BT conectados, transferencia corriendo) antes de darlo por confirmado.

2. El badge "Receiving…" no se quitaba nunca en una canción fallida

playlistIdsReceiving contaba cualquier entrada presente en activeTransfers como "recibiendo", sin mirar el status — pero una transferencia fallida se queda a propósito en ese mapa (para que DownloadsScreen la liste bajo "Transfer issues"). Ahora solo STATUS_TRANSFERRING cuenta como "activa".

3. Sin reintento — una canción fallida se perdía directo

El plan original ya contemplaba "reintento con backoff" para este escenario exacto, pero nunca se implementó. Con datos reales confirmamos que hace falta: 2 de 6 canciones se perdieron en una sola corrida, ambas consistentes con un stall de Bluetooth por compartir el radio con los audífonos BT conectados — una condición real, no un enlace roto. transferSongToAllNodesWithRetry reintenta una vez, con un backoff corto, antes de que el coordinador dé la canción por perdida.

Verificado

• ./gradlew :wear:compileDebugKotlin :app:compileDebugKotlin :shared:compileDebugKotlin — BUILD SUCCESSFUL.
• ./gradlew :wear:testDebugUnitTest :app:testDebugUnitTest --tests "...PlaylistWatchTransferCoordinatorTest" --tests "...WearLocalPlaylistViewModelTest" — 27 tests en verde (17 + 10, incluye 4 nuevos/actualizados: retry exitoso, retry que también falla, cancelación durante el backoff, badge no cuenta transferencias fallidas).
• ./gradlew :shared:testDebugUnitTest — sin fallos.
• Confirmé que los 5 fallos preexistentes de :app (BackupSectionTest, LoadControlBufferProfileTest, LyricsStateHolderTest, AudioMetaUtilsTest, LocalArtworkUriTest) no están relacionados — ya se habían verificado como preexistentes en el PR anterior, no los toco.

Sin verificar (necesita el mismo escenario de hardware)

• Que el arreglo del watchdog realmente evite las canciones perdidas — la próxima corrida con audífonos BT + transferencia debería mostrar como máximo un "timed out" transitorio seguido de reintento, nunca un "metadata missing" ni pérdida real.
• No toqué el valor del timeout (120s) a propósito: con la cancelación correcta + el reintento, disparar de más ya no es peligroso, solo dispara un reintento barato — cambiar el número sin más datos hubiera sido ajuste a ciegas.

Pendiente, fuera de este PR

Del mismo ciclo de pruebas: la reproducción local en el reloj se entrecorta al punto de ser inutilizable, incluso sin ninguna transferencia corriendo — hallazgo separado y más grave, ya no es "afinamiento de Fase 2" sino un bloqueante real (audio offload, LoadControl sin dimensionar). Se aborda en un PR aparte.