FreeTLab
9c7cf4e261
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.