fix(alarm): anchor snooze to the ringing occurrence, never a future one

posponerAlarma anchored the snooze to snoozeOrigen ?? proximaEjecucion,
but once the native fire path works, the fire-time sync records the
handled occurrence and recalculation advances proximaEjecucion to the
NEXT day before the user can even tap snooze on the still-ringing
screen. "Posponer 3" therefore armed the snooze a full day out
(captured on-device: snoozeCountdown remaining=1443 minutes). The bug
was invisible before because the broken delivery path never advanced
proximaEjecucion while ringing — each fix unmasked the next.

The anchor is now the newest occurrence that is not meaningfully in
the future (shared 90s imminence window): snoozeOrigen for re-snoozes,
proximaEjecucion on the watchdog path where it is still today's
just-due occurrence, ultimaEjecucionGestionada on the native-fire path
where the sync recorded the ringing occurrence, then now. ServicioAlarmas
exposes ahora() so the anchor uses the same injectable clock as the
rest of the scheduling math. Test fixtures that snoozed half an hour
before the ring — a state the ringing screen can never be in, since it
is posponerAlarma's only production caller — now move the clock to
ring time, preserving their original expectations.

lib/servicios/servicio_alarmas.dart

@@ -35,6 +35,11 @@ class ServicioAlarmas {
   final DateTime Function() _reloj;
   final _uuid = const Uuid();
 
+  /// Current time through the injected clock, so callers that need "now"
+  /// (e.g. the ring screen's snooze anchor) stay testable with the same
+  /// fixture clock the service itself computes with.
+  DateTime ahora() => _reloj();
+
   // In-memory cache + single-writer queue (Design 3.5 / S3-R7): every
   // mutation runs serialized through [_enCola] and reads [_cache], killing
   // the read-modify-write race the old cargar()-before-each-mutation had.