fix(onboarding): request notification permission after welcome screen renders (#168)

* fix(onboarding): request notification permission after welcome screen renders

The POST_NOTIFICATIONS request fired from a MainActivity-root
NotificationPermissionEffect whose LaunchedEffect(Unit) ran on the very
first composition, so the system dialog could pop the instant the icon
was tapped — overlapping cold start/splash before any onboarding context
was on screen.

Move the effect into OnboardingWelcomeScreen so it fires once that screen
(the onboarding start destination) is composed and visible, with the
welcome content behind the dialog. Already-onboarded users launch
straight into the mailbox and never compose the welcome screen, so they
are unaffected; the API 33+ gate and the already-granted no-op are
preserved unchanged.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* test(onboarding): grant POST_NOTIFICATIONS in onboarding E2E to fix API 33+ flow

Moving the notification-permission request into OnboardingWelcomeScreen
(#151) means the system POST_NOTIFICATIONS dialog now pops when that
screen composes. On API 33+ (where it became a runtime permission) the
dialog backgrounded the activity mid-flow, so OnboardingFlowTest failed
with "No compose hierarchies found" on API 33/34/35/36/37 while API
29–32 stayed green.

Pre-grant the permission via a GrantPermissionRule so the dialog never
appears during the flow, guarded for API 33+ (the permission does not
exist below TIRAMISU, so grant nothing there to avoid erroring on older
devices). Adds the androidx.test:rules dependency that provides the rule.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

docs/play-permissions.md

@@ -62,14 +62,16 @@ Nothing else. Notably **absent** (worth stating in any review exchange):
   `notifications/MailNotifier.kt` (no push/cloud-messaging service; lock-screen content
   redacted via `VISIBILITY_PRIVATE`); (2) the persistent low-importance status notification
   Android requires while the IMAP IDLE foreground service runs (`push/IdleService.kt:120`).
-- **Request flow:** once at first launch, API 33+ only (`MainActivity.kt`
-  `NotificationPermissionEffect`). If denied, `MailNotifier.notifyNewMail` no-ops (permission
+- **Request flow:** once, when the onboarding welcome screen appears, API 33+ only
+  (`ui/onboarding/OnboardingWelcomeScreen.kt` `NotificationPermissionEffect`, scoped to that
+  screen's composition so the system dialog shows onboarding context instead of racing the
+  cold-start/splash transition — #151). If denied, `MailNotifier.notifyNewMail` no-ops (permission
   re-checked before every post, `MailNotifier.kt:134`); mail sync itself is unaffected.
 - **Play-Console justification text (if asked):**
   > Notifies the user of newly received email (per-account channels, generated on the device
   > from the user's own mailbox — no push service) and shows the persistent status notification
-  > Android requires for the optional foreground IMAP IDLE connection. Requested once at first
-  > launch; all app functions except notifications work if declined.
+  > Android requires for the optional foreground IMAP IDLE connection. Requested once, when the
+  > onboarding welcome screen appears; all app functions except notifications work if declined.
 
 ## `FOREGROUND_SERVICE_DATA_SYNC` (requires the Play Console FGS declaration)