Fix prediction reminder re-arming, daily reminder reliability, and alarm scheduling bugs

[mapgie]

Part of a cross-app review of how the four apps use AlarmManager for alarms and reminders. This PR fixes the GoFlo findings, the largest set of the four.

Bugs fixed

• Prediction reminders never re-armed. Pre-period, ovulation, and daily reminders are one-shot alarms that were only armed at boot and from the reminder settings screen. After a reminder fired, or after the user logged a period (which moves every predicted date), nothing re-armed them, so the feature quietly degraded to "works until the first firing". A shared ReminderScheduler.refreshPredictionReminders() is now called from ReminderReceiver after each prediction firing and from every period mutation (log, edit, delete, undo, merge).
• The daily during-period reminder used setRepeating, which is inexact and Doze-deferred since KitKat, so it could arrive hours late or not at all. It is now an exact one-shot that re-arms itself via the receiver while a period is active, and ends naturally when the period ends.
• Pre-Android-12 devices always got inexact alarms. The gating condition SDK >= S && canScheduleExactAlarms() sent every pre-12 device down the inexact branch, even though exact alarms need no permission there. Centralised into canUseExactAlarms()/setAlarm() and applied to custom alarms, prediction reminders, and snooze.
• Deleting or disabling a custom alarm left its snoozed firing armed. The snooze PendingIntent (request code 40000+id) was never cancelled, and the receiver did not check isEnabled at fire time. Snooze identity now lives in ReminderScheduler.customAlarmSnoozePendingIntent, cancelCustomAlarm cancels it, and the receiver checks isEnabled.
• A repository exception could break a recurring alarm chain. Recurring custom alarms are now re-armed before condition evaluation and notification display.
• DST drift. Next-trigger times were computed by adding 86,400,000 ms, which lands an hour off across DST transitions; they are now resolved per local calendar day.
• Boot-only rescheduling. BootReceiver now also handles MY_PACKAGE_REPLACED, TIMEZONE_CHANGED, and TIME_SET (all exempt from implicit-broadcast restrictions, no new permission), since every alarm is armed at an absolute epoch computed from local times.

Known issue left out (needs a permissions discussion)

ALARM-type custom alarms call setFullScreenIntent, but the manifest does not declare USE_FULL_SCREEN_INTENT. On Android 14+ targets the full-screen alarm UI is silently downgraded to a heads-up notification. Adding the permission is a one-line change, but Play policy restricts full-screen intent for non-alarm-category apps and CLAUDE.md requires discussion before adding permissions, so it is flagged here rather than changed.

Changelog fragment: changelog/unreleased/alarm-reliability.json (patch). LESSONS.md gains an entry on re-arming data-dependent one-shot alarms. a11y_check.py passes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Qs1UZLKHTxtaLpTheoUwTg

---

Generated by Claude Code