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/servicio_audio_session.dart

@@ -1,5 +1,4 @@
 import 'dart:async';
-import 'dart:developer' as developer;
 
 import 'package:audio_session/audio_session.dart';
 import 'package:flutter/foundation.dart';
@@ -89,10 +88,8 @@ class ServicioAudioSession {
         (_) => unawaited(manejarDesconexionSalida()),
       );
     } catch (e) {
-      developer.log(
-        '[PluriWave] No se pudo configurar la sesion de audio: $e',
-        name: 'ServicioAudioSession',
-        level: 900,
+      debugPrint(
+        '[PluriWave][ServicioAudioSession] No se pudo configurar la sesion de audio: $e',
       );
     }
   }