feat(audio): log AudioService.asyncError instead of swallowing it

`AudioService.asyncError` had ZERO subscribers app-wide. The plugin funnels
every asynchronous failure of its own observers into that stream and nowhere
else — `_observePlaybackState`, `_observeMediaItem` and `_observeQueue` each
wrap their whole body in `catch (e) { _asyncError.add(e); }`, and the artwork
path uses `.catchError(_asyncError.add)` — and a `PublishSubject` with no
listeners simply drops what it is given. The platform-side exception behind
"the media playback notification disappeared" was therefore being discarded
without a single log line, which is why that report arrives with no evidence
attached.

`observarErroresAudio` is a pure, injectable seam in `arranque_audio.dart`
(stream in, logger callback out), matching the seam convention this codebase
already uses for `esperarArranqueAudio`, `decidirAvanceCola` and
`debeReaplicarEcualizador`: the unit tests exercise the wiring with a plain
`StreamController`, never the real plugin. The default logger emits one
`[PluriWave]`-prefixed `developer.log` line at `level: 900`, the same level
and prefix `servicio_audio.dart` already uses, so one logcat filter catches
both.

Wired from `lib/main.dart`, not from `arranque_audio.dart`: main.dart is the
module that genuinely owns handler lifecycle — it is the only caller of
`AudioService.init`, `registrarHandler` and `ServicioAudioSession`, and both
the on-time and the degraded/timeout startup branches converge on its
`conectarHandler` closure. `arranque_audio.dart` owns only the timeout race
and the degraded loading shell; it never creates or registers a handler
(`alListo` is injected into it from main.dart), so it has no lifecycle to
hang a subscription on. Subscribing happens before `AudioService.init` — the
getter only touches a static subject — so nothing reported during the
MediaBrowser handshake is missed, and one subscription covers both paths.

The subscription is cancellable and its `cancel` is registered into the
handler via `registrarLimpiezaArranque`, mirroring the existing
`registrarHandler` / `registrarFuenteNavegacion` / `registrarFuenteMusicaLocal`
registration convention. `onTaskRemoved` — the only handler teardown in this
app — runs it, so the subscription cannot outlive what it instruments. The
dependency points bootstrap -> service, so `servicio_audio.dart` never has to
import the bootstrap module or the plugin's static stream.

Zero behaviour change: nothing but log output is added.

lib/servicios/arranque_audio.dart

@@ -1,4 +1,5 @@
 import 'dart:async';
+import 'dart:developer' as developer;
 
 import 'package:flutter/material.dart';
 
@@ -58,6 +59,53 @@ Future<ResultadoArranqueAudio<T>> esperarArranqueAudio<T>(
   }
 }
 
+/// Subscribes to [errores] — in production `AudioService.asyncError` — and
+/// hands every event to [registrar]. Returns the [StreamSubscription] so the
+/// caller can cancel it when the handler is torn down.
+///
+/// Why this exists: `audio_service` funnels EVERY asynchronous failure of its
+/// own observers into that stream and nothing else
+/// (`_observePlaybackState`/`_observeMediaItem`/`_observeQueue` each wrap
+/// their whole body in `catch (e) { _asyncError.add(e); }`, and the artwork
+/// path uses `.catchError(_asyncError.add)`), yet this app had ZERO
+/// subscribers on it. A `PublishSubject` with no listeners simply drops
+/// events, so the platform-side exception behind "the media notification
+/// disappeared" — a rejected `setState`, a failed `setMediaItem`, an
+/// Android 12+ `ForegroundServiceStartNotAllowedException` surfacing through
+/// the plugin — was being discarded without a single log line. This makes
+/// that channel audible.
+///
+/// [errores] and [registrar] are both injected — this function never touches
+/// the real `audio_service` plugin, so it is testable with a plain
+/// [StreamController] (same seam convention as [esperarArranqueAudio] above,
+/// and as `decidirAvanceCola`/`debeReaplicarEcualizador` elsewhere).
+StreamSubscription<Object> observarErroresAudio(
+  Stream<Object> errores, {
+  required void Function(Object error) registrar,
+}) {
+  return errores.listen(
+    registrar,
+    // The plugin only ever feeds this subject through `add`, never
+    // `addError`, so this branch is purely defensive: a stream-level error
+    // would otherwise escape as an unhandled zone error, which is strictly
+    // worse than one more log line.
+    onError: (Object error, StackTrace _) => registrar(error),
+    cancelOnError: false,
+  );
+}
+
+/// Default [observarErroresAudio] logger: one `[PluriWave]`-prefixed
+/// `developer.log` line per swallowed plugin exception, at the same
+/// `level: 900` (SEVERE) that `servicio_audio.dart`'s existing error lines
+/// use, so a single logcat/DevTools filter catches both.
+void registrarErrorAudioService(Object error) {
+  developer.log(
+    '[PluriWave] AudioService.asyncError: $error',
+    name: 'ArranqueAudio',
+    level: 900,
+  );
+}
+
 /// Minimal branded bootstrap widget for the degraded path (Design "still
 /// call runApp, but with a minimal bootstrap widget that keeps waiting on
 /// the SAME original future"). Shows [_CargandoArranqueAudio] while