Notifications: scheduled & triggered local notifications (calendar / interval / location)

[proggeramlug]

notificationSend always fires with a 0.1s UNTimeIntervalNotificationTrigger (crates/perry-ui-macos/src/notifications.rs:41) — no way to schedule.

Scope

• New TS surface:

  export function notificationSchedule(opts: {
    id: string;
    title: string;
    body: string;
    trigger: { type: "interval"; seconds: number; repeats?: boolean }
           | { type: "calendar"; date: Date }
           | { type: "location"; latitude: number; longitude: number; radius: number };
  }): void;
  export function notificationCancel(id: string): void;

• iOS/macOS: UNTimeIntervalNotificationTrigger / UNCalendarNotificationTrigger / UNLocationNotificationTrigger.
• Android: AlarmManager → NotificationManager for interval/calendar; Geofencing API for location.
• Windows: toast scheduling via ToastNotifier.AddToSchedule.
• Linux/Web: best-effort; document limits.

Identifier map lives runtime-side so cancel works.

[proggeramlug]

Closed — notificationSchedule (interval + calendar) and notificationCancel ship on both Apple and Android.

• TS surface: notificationSchedule({id, title, body, trigger}) with discriminated-union trigger ("interval" | "calendar" | "location") + notificationCancel(id). Codegen requires trigger.type to be a string literal at the call site so the right runtime fn is picked at compile time.
• Apple (v0.5.244, commit 7ef745b): interval → UNTimeIntervalNotificationTrigger, calendar → NSDateComponents via NSCalendar wrapped in UNCalendarNotificationTrigger, location → CLCircularRegion in UNLocationNotificationTrigger (iOS only — macOS logs a no-op since the UN-side trigger is iOS-only). Cancel via removePendingNotificationRequestsWithIdentifiers: + removeDeliveredNotificationsWithIdentifiers:. Added -framework CoreLocation to the iOS link line.
• Android (v0.5.260, commit 405363e): PerryScheduledNotificationReceiver BroadcastReceiver fires when AlarmManager hits and posts the notification with the same channel + tap-routing as sendNotification. scheduleInterval uses setRepeating (repeats=true, capped at 60s minimum) or setAndAllowWhileIdle (one-shot). scheduleCalendar uses setAndAllowWhileIdle — inexact but Doze-safe and permission-free. Cancel tears down both the AlarmManager registration and any displayed notification.

Inexact-alarm trade-off documented: apps needing exact wall-clock fire have to request SCHEDULE_EXACT_ALARM themselves and switch to setExactAndAllowWhileIdle.

Out of scope, deferred to follow-up issues if needed:

• Android Geofencing (scheduleLocation is a logged no-op — needs FUSED_LOCATION_PROVIDER from Google Play Services + ACCESS_FINE_LOCATION runtime grant)
• Windows ToastNotifier scheduling
• Linux/Web best-effort
• Android BOOT_COMPLETED receiver to re-arm scheduled alarms after device reboot