fix(mobile): recover push activation when the notification permission is blocked

[JordiMa]

Problem

Users reported that enabling push notifications in the Android app sometimes does nothing — not reproducible on every phone.

Two root causes, which reinforce each other:

1. Permanently blocked permission = silent dead end. On Android 13+, the system only allows the notification permission prompt to be shown twice. Once that budget is spent (or when notifications are disabled for the app in system settings), requestPermissionsAsync() returns denied instantly without showing any dialog. The toggle just snapped back with a generic "permission denied" message and no way to recover from inside the app. Whether a phone is in this state depends on its denial history, which explains the inconsistent reproduction.

2. A concurrent duplicate permission request burned both prompts in one interaction. The settings screen has a passive re-registration effect keyed on push_enabled. The toggle's optimistic cache update fired that effect mid-activation, so a second requestPermissionsAsync() was queued behind the toggle's own request (expo-modules-core queues concurrent requests). If the user denied the first dialog, the second (and final) one appeared immediately behind it — a single decline could permanently block the permission, feeding phones into state 1.

Fix

• PushNotificationService.requestExpoPushToken() now returns a PushTokenRequestStatus (Granted / Denied / Blocked / Unsupported) instead of a bare token, using canAskAgain to detect the permanently blocked state.
• When blocked, registerDeviceForPush shows a native alert with an Open settings action (Linking.openSettings()) that deep-links to the app's system settings, plus an inline explanation message. The onboarding enable-push flow benefits from the same handling.
• The passive re-registration effect in use-settings.ts now uses the non-prompting getGrantedExpoPushToken(), so only the toggle itself can trigger the permission prompt — the duplicate-request race is gone, and opening the settings screen can no longer spontaneously show a permission dialog.
• New en/fr strings for the blocked state.

Tests

• 11 new tests covering requestExpoPushToken() status resolution (already granted, granted from prompt, denied-but-askable, permanently blocked, web).
• Full mobile suite, nx typecheck mobile, lint, and nx export mobile all pass.

Notes

• For users already in the permanently blocked state, the app cannot re-open the system prompt (OS limitation) — but they now get a button that takes them to the right settings screen instead of a silent failure.
• While tracing this I found a separate, opposite bug: the silent token re-registration on app open forces push_enabled: true server-side, so turning push OFF does not survive an app restart. Left out of scope here; can open a follow-up if wanted.