Fix foreground service start-timeout crash path

[callebtc]

Summary

• call startForegroundService only when background mode plus Bluetooth/location and notification permissions allow immediate foreground promotion
• promote service to foreground before mesh startup work in onStartCommand to avoid timeout windows
• remove eager mesh holder initialization from onCreate to reduce startup latency before foreground promotion

Testing

• ./gradlew :app:compileDebugKotlin -q

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f40f27ddf5

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Re-trigger foreground start after runtime Bluetooth grant

This new guard skips startForegroundService whenever Bluetooth/location permissions are not already granted, but there is no automatic retry path once those permissions are granted later in the same app session (the existing call sites invoke MeshForegroundService.start(...) only during startup/toggle flows). On first-launch permission onboarding for API 26+ devices, users can complete grants and still never get the foreground service/notification until they relaunch or manually toggle background mode, which leaves background mesh behavior unexpectedly disabled.

Useful? React with 👍 / 👎.