fix(audio): make the audio diagnostics visible in release builds

Every diagnostic line in the audio path used `dart:developer`'s `log()`.
That function writes to the VM service, which a RELEASE build does not
have — so in the only build that ever runs in a car, all eleven of them
went nowhere. `debugPrint`/`print` do reach logcat in release; `log()`
does not.

That includes the two channels built specifically to end the guessing:
- `registrarErrorAudioService`, which subscribes to
  `AudioService.asyncError` so the plugin's swallowed platform exceptions
  stop vanishing (b0271fa). It moved them from a dropped PublishSubject
  to a dropped log call.
- `_trazarEstadoPublicado`, the published-state trace added in 7054a4c to
  settle why the car's play button never becomes pause.

So "no evidence" was never a quiet app. It was an app writing its
evidence somewhere release builds discard. Several rounds of hypotheses
were argued without data that the app was already producing.

All eleven now use `debugPrint` with a `[PluriWave][Tag]` prefix, so one
filter catches the audio path and the existing alarm lines together:

  adb logcat | grep PluriWave

No behaviour changes. Tests: 1158, unchanged.

lib/servicios/cola_local.dart

@@ -97,7 +97,5 @@ DecisionAvanceCola decidirAvanceCola({
 /// distinct `ColaLocal` during the async URI-resolve gap is correctly
 /// detected as stale and aborts the advance, instead of silently racing an
 /// external play/stop.
-bool avanceEsValido(
-  ColaLocal? colaLocalActual,
-  ColaLocal? siguienteEsperado,
-) => identical(colaLocalActual, siguienteEsperado);
+bool avanceEsValido(ColaLocal? colaLocalActual, ColaLocal? siguienteEsperado) =>
+    identical(colaLocalActual, siguienteEsperado);