fix(todo): the permission to notify asked wherever a reminder is planned, and Settings saying while it is off (ADR 0033, D31)

On a fresh install Todo's reminders never showed: the permission to notify
(Android 13's POST_NOTIFICATIONS, iOS' and macOS' alert) was asked only
where a task's sheet chose its first reminder, so reminders typed in quick
add, added by the automatic reminder or brought by sync were scheduled and
dropped by the system without a word.

Now NotificationAccess, the device's, reads whether notifications are
allowed whenever the plan holds a reminder and asks where they aren't,
once an app start, so that a refusal isn't met with the dialog again and
again; the task sheet asks through it. While reminders are planned and
notifications are off, Settings' Reminders say so, with Turn on: asked
again, and where that doesn't allow it, the system's notification settings
of the app opened (flutter_local_notifications' own call, nothing added).
Read again whenever the app comes back.

Whats-New: Todo asks to notify as soon as there is a reminder, and Settings › Reminders shows when notifications are off, with Turn on.
Whats-New-De: Todo fragt nach Benachrichtigungen, sobald es eine Erinnerung gibt, und Einstellungen › Erinnerungen zeigt, wenn sie aus sind, mit Einschalten.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>

docs/adr/0033-halkyon-todo.md

@@ -131,7 +131,9 @@ the rail, a wash of strawberry, settings grouped as theirs. What the screenshots
   there the running app shows them. Android brings them at the minute only where the
   person allows exact alarms (`SCHEDULE_EXACT_ALARM`, off by default since Android 14),
   else within a few minutes; the app doesn't send the person to that setting. The
-  permission to notify is asked when a task first gets a reminder; a notification's
+  permission to notify is asked when a task first gets a reminder (both amended by
+  D31: exact alarms through `USE_EXACT_ALARM`, the permission asked wherever a reminder
+  is planned); a notification's
   text, the task's title, is hidden on a locked Android screen. Signing out, or
   switching person, cancels the person's reminders on the device. Tapping one opens the
   app, not yet its task.
@@ -560,6 +562,43 @@ The developer's review of 4 Nov 2026, again beside Todoist's screens.
   wide windows alone (a phone couldn't plan by dragging), a strip above the day
   (too little room for three groups), the project filter synced (a planning
   session's narrowing would follow the person to their other devices).
+- **D31 Reminders at the minute, and the permission to notify asked wherever one is
+  planned** (the developer's, 4 Nov 2026, after Todo's reminders never showed on a
+  phone, GrapheneOS on Android 14, installed afresh from F-Droid). Two faults: the
+  permission to notify (Android 13's `POST_NOTIFICATIONS`, iOS' and macOS' alert) was
+  asked only where a task's sheet chose its first reminder, so reminders typed in quick
+  add (`!30m`, `!1pm`), added by the automatic reminder (D4) or brought by sync were
+  planned and scheduled, and the system dropped every one without a word; and exact
+  alarms, `SCHEDULE_EXACT_ALARM`, are off from Android 14 on until the person allows
+  them in *Alarms & reminders*, so they came inexact, minutes late.
+  - **Asked wherever a reminder is planned**: whenever the plan of the device's
+    reminders holds one (`ReminderScheduler`), `NotificationAccess` reads whether the
+    device may notify (`ReminderGateway.notificationsAllowed`: Android's
+    `areNotificationsEnabled`, Apple's `checkPermissions`; Linux and Windows ask
+    nothing) and where it may not, asks, **once an app start**, the device's and not the
+    person's: refused, nobody is asked again and again (Android itself stops showing
+    its dialog after two refusals, iOS after one). The task sheet's ask goes through the
+    same place, so the plan's doesn't follow it.
+  - **Settings › Reminders says *Notifications are off*** while reminders are planned
+    and the device may not show them, with *Turn on*: asks again, and where that doesn't
+    allow it (refused again, or the system asks no more), opens the system's
+    notification settings of the app (the plugin's `openAppNotificationSettings`, no
+    package or platform code of Halkyon's added). Read again whenever the app comes
+    back, so notifications allowed there count at once. (Agent's choice: Turn on asks
+    first and opens the settings after a refusal, over telling the two apart with
+    Android's `shouldShowRequestPermissionRationale`, which would have needed a method
+    channel of the app's own for a case that ends in the settings either way.)
+  - **Exact alarms through `USE_EXACT_ALARM`** (the developer's choice), granted with the
+    install from Android 13 on to an app whose purpose is reminding of what a person
+    planned (calendars, alarm clocks, reminders), with `SCHEDULE_EXACT_ALARM` still
+    declared for Android 12 and 12L, which don't know the other, up to API 32 alone
+    (`test/android/exact_alarms_test.dart`). `AlarmManager.canScheduleExactAlarms` is
+    true with either, so the plugin's `canScheduleExactNotifications` is, and reminders
+    are `exactAllowWhileIdle`. *Alternatives:* leading the person to *Alarms &
+    reminders* (one more permission to ask and explain, which most would never find
+    again once refused), staying inexact (reminders minutes late, which a reminder at a
+    time can't be). Google Play reviews `USE_EXACT_ALARM` against that purpose; Todo is
+    one, and F-Droid asks nothing of it.
 
 ## Steps