Reschedule due-card reminders on all mutation paths

[Pairadux]

Problem

Due-card reminders are currently rescheduled only on:

• App launch (via `notificationBootstrapProvider`)
• Study session end (two call sites in `StudySessionScreen`)
• Notification settings change

Other mutations that affect due dates are not covered:

• Deleting a due card — notification may fire for a day with no remaining due cards
• Sync pull — new due dates may arrive (or existing ones may be removed) from another device
• Bulk operations (future) — move/delete affecting due dates

Desired behavior

At each mutation point, ensure the scheduled notification set matches the actual distinct due dates. No full wipe-and-reschedule — instead, diff the currently-scheduled IDs against the fresh due-date set and only cancel/add the delta.

Since notification IDs are date-based (`YYYYMMDD`), we only care about which days have at least one due card — no count recalculation needed. This keeps the cost proportional to the number of changed days, not the total number of scheduled notifications.

Approach (suggestion)

1. Add an incremental `syncSchedule()` method to `DueReminderScheduler` that:
   • Queries `getDistinctDueDates()`
   • Loads the currently-persisted scheduled IDs
   • Computes the diff (IDs to cancel, IDs to add)
   • Only touches the delta
2. Call `syncSchedule()` (not `rescheduleAll()`) from:
   • Card delete (single + future bulk)
   • Sync pull completion
3. Keep `rescheduleAll()` for app launch and settings changes where a full rebuild is appropriate.

Performance constraint

This must not add perceptible latency to card mutations. The `getDistinctDueDates()` query is already indexed and lightweight, but it should still be fire-and-forget (`unawaited`) at call sites where the user is waiting on a UI transition.

[Pairadux]

Edge cases to consider

Concurrency on the persisted ID list — If a sync pull completes right as a card deletion triggers syncSchedule(), both read the same persisted IDs, compute independent diffs, and one overwrites the other's save. Needs an async queue/mutex to serialize calls.

The 30-notification cap — Can't blindly add new dates. Must maintain the nearest-30 sliding window. E.g., if a deletion removes day 5, a previously-excluded day 31 should get picked up. The diff is really "rebuild the nearest-30 window and diff against current," not a naive set difference.

Stale past-date IDs accumulating — rescheduleAll() implicitly cleans up past dates by wiping everything. The incremental approach needs to explicitly prune past dates from the persisted list during each sync, or the list grows indefinitely.

Study session pause + resume flush — Sync is paused during study. On session end, the post-session reschedule and the sync resume (which triggers a pull → syncSchedule()) could overlap. Falls under the concurrency point — serialization handles this.