Guard settings intents against missing activities

[in-jun]

The onboarding permission banner launches three system settings actions (all-files-access, per-app notifications, battery-optimization exemption). A matching activity for these isn't guaranteed on every device/OEM build, so on an affected phone tapping the banner threw ActivityNotFoundException and crashed the app during first-run.

• Route all four settings launches through a startFirstAvailable helper that tries each action in order, swallows ActivityNotFoundException, and falls back to the device-wide list where one exists and finally the always-present app details page.

Fixes #69

[in-jun]

Confirmed this resolves #69 cleanly. All four startActivity sites in Permissions.kt — the only settings launches in the app — now route through startFirstAvailable, which tries each action in order, swallows ActivityNotFoundException, and lands on the always-present app-details page as a last resort. The preferred intent is still attempted first in every case, so happy-path behavior is unchanged and the only new behavior is the fallback chain.

A couple of things I checked:

• Fallback constants are safe at our minSdk 26: ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS (23) and ACTION_APP_NOTIFICATION_SETTINGS (26) are always available, and ACTION_MANAGE_ALL_FILES_ACCESS_PERMISSION (30) stays inside the existing SDK_INT >= R guard.
• If every intent fails the call is a harmless no-op rather than a crash, which is the whole point of the change.

The device-wide list / app-details fallbacks drop the user a step short of the exact toggle, but that's a reasonable trade for never crashing the first-run flow, and it matches the approach outlined in the issue. Looks good to me.