fix(favoritos): use the cross-version onReorder API and correct drag index math

The CI Flutter SDK predates v3.41 and only exposes ReorderableListView's
onReorder; the newer onReorderItem broke the build with three analyzer
errors. onReorder exists in both SDKs, so use it and compensate for its
pre-removal newIndex internally.

Fixing the call site surfaced a real ordering bug: _onReorder located the
target neighbour in the untrimmed global list, while ServicioFavoritos
.reordenar inserts into the list after the station is removed. Dragging a
station downwards past its neighbours therefore landed it one slot too far.
Adds a mid-list downward-drag test, the only case that separates the two
coordinate spaces.

test/l10n/arb_anti_copy_test.dart

@@ -44,8 +44,8 @@ void main() {
     for (final locale in _auditedLocales) {
       final arb = readArb(locale);
       for (final key in realKeys(arb)) {
-        if (!es.containsKey(key))
-          continue; // arb_parity_test's job, not this one's
+        // Missing keys are arb_parity_test's job, not this one's.
+        if (!es.containsKey(key)) continue;
         if (arb[key] == es[key] &&
             !identicalValueAllowlist.contains((locale, key))) {
           unlisted.add('$locale/$key = "${arb[key]}"');

test/pantallas/pantalla_favoritos_test.dart

@@ -226,10 +226,13 @@ void main() {
       find.byType(ReorderableListView),
     );
     // Drag the 3rd row (index 2, "Station C") to the 1st position (index
-    // 0) — exercised via the real onReorderItem callback the widget wires
-    // up. onReorderItem (not the deprecated onReorder) already adjusts
-    // newIndex for the removed item, so no manual index math here.
-    lista.onReorderItem!(2, 0);
+    // 0), exercised via the real onReorder callback the widget wires up.
+    // `onReorder` is the API present across Flutter versions (the newer
+    // `onReorderItem` does not exist on the CI SDK), so it reports
+    // newIndex in the PRE-removal coordinate space; `_onReorder`
+    // compensates internally. Moving upwards needs no shift, which is why
+    // (2, 0) maps straight through.
+    lista.onReorder!(2, 0);
     await pumpStable(tester);
 
     expect(estado.listaFavoritosManual.map((e) => e.uuid).toList(), [
@@ -247,6 +250,40 @@ void main() {
     ]);
   });
 
+  testWidgets('dragging the 1st item downwards lands it in the right slot', (
+    tester,
+  ) async {
+    // Guards the pre-removal index compensation in `_onReorder`. Downward
+    // drags are the ONLY direction `ReorderableListView.onReorder` reports
+    // in the pre-removal coordinate space, so an off-by-one here would slip
+    // past the upward-drag test above entirely.
+    setLargeSurface(tester);
+    _suppressListTileInkAssertion();
+    final estado = await crearEstadoConFavoritos();
+    addTearDown(estado.dispose);
+
+    await tester.pumpWidget(buildScreen(estado));
+    await pumpStable(tester);
+
+    final lista = tester.widget<ReorderableListView>(
+      find.byType(ReorderableListView),
+    );
+    // Move "Station A" (index 0) into the MIDDLE slot. onReorder reports
+    // newIndex == 2 in the pre-removal space; `_onReorder` shifts it to 1.
+    // This specific case is what makes the test meaningful: dropping at the
+    // very end (0, 3) yields the same answer with or without the shift,
+    // because both land in the `newIndex >= restantes.length` branch. Only a
+    // mid-list drop separates the two.
+    lista.onReorder!(0, 2);
+    await pumpStable(tester);
+
+    expect(estado.listaFavoritosManual.map((e) => e.uuid).toList(), [
+      'b',
+      'a',
+      'c',
+    ]);
+  });
+
   testWidgets(
     'swap_vert sort action applies OrdenEmisoras.nombre and re-renders '
     'alphabetically',