fix(auto): restore the equalizer toggle and list the user's own presets

Two Android Auto regressions reported from the car.

1. The on/off equalizer action disappeared from the playback screen.

That was self-inflicted: commit cacd3ec removed it on the theory that a
custom action in `controls` aborts `AudioService.setState` and kills the
media notification. Reading the plugin source refutes it. setState
(AudioService.java:513-520) SPLITS the list -- a control carrying a
customAction goes to `customActions` (PlaybackStateCompat, i.e. the car),
everything else becomes a NotificationCompat.Action in `nativeActions`
(the phone notification). The two never mix. And the throw the theory
depended on cannot happen here: ic_auto_eq_on/ic_auto_eq_off both exist
under res/drawable, and the labels are non-empty in all 13 locales.

The notification outage was already fixed by abc6b47 (transient idle on
a source change, which setState turns into a full stop() at :557).

The action is back, with both state-aware icons. The real invariant --
a custom action's icon must resolve and its label must be non-empty --
is now a test that reads res/drawable and fails on a missing file,
instead of a comment claiming custom actions are forbidden outright.

2. The Ecualizador folder never listed the user's saved presets.

itemsEcualizadorAuto iterated PresetEcualizador.presets, so only the six
factory presets appeared -- the user's own were unreachable from the
car, the surface where a preset picker matters most. They now arrive
through a registered read function (same seam as stations and local
music, re-read per browse so a preset saved on the phone shows up
without an app restart).

presetsEcualizadorAuto is the single source of truth for the ordered
universe, used to BUILD the items and to RESOLVE a tap, so the folder
cannot show an item that resolution then refuses -- which is what the
factory-only default in seleccionarPresetEqPorMediaId would have caused.
A custom preset whose name collides with a factory one is dropped: the
media id is the raw name, so it could only ever resolve to the factory
entry, and an item that applies a preset other than the one it names is
worse than an absent one.

Tests: 1108 -> 1120.

lib/servicios/navegacion_auto.dart

@@ -954,11 +954,18 @@ Future<void> reproducirPorMediaId(
 /// A stale/unresolvable id, or any id that doesn't match
 /// [ConstructorArbolAuto.esPresetEqMediaId], is a no-op: neither callback
 /// runs and no exception propagates.
+///
+/// [presets] is the universe the id is resolved against, and it MUST be the
+/// same list the folder was rendered from (`presetsEcualizadorAuto` in
+/// `servicio_audio.dart` — factory presets plus the user's saved ones).
+/// Defaulting to the factory six alone is what made a tapped custom preset a
+/// silent no-op: the item was listed, but nothing here could resolve it.
 Future<void> seleccionarPresetEqPorMediaId(
   String id, {
   required bool activo,
   required Future<void> Function(PresetEcualizador) aplicarPreset,
   required Future<void> Function(bool) activarEcualizador,
+  List<PresetEcualizador>? presets,
 }) async {
   final constructor = ConstructorArbolAuto();
   if (!constructor.esPresetEqMediaId(id)) return;
@@ -968,7 +975,7 @@ Future<void> seleccionarPresetEqPorMediaId(
     return;
   }
 
-  final preset = constructor.resolverPresetEq(id);
+  final preset = constructor.resolverPresetEq(id, presets: presets);
   if (preset == null) return;
 
   await aplicarPreset(preset);