Fix screen not turning on at Bluetooth connect with KeepAwake

[d4rken]

Fixes the long-standing issue where the screen does not wake at Bluetooth connect even with KeepAwake enabled and all permissions granted.

Root cause: WakeLockManager was using SCREEN_BRIGHT_WAKE_LOCK | ON_AFTER_RELEASE, which has been functionally deprecated since API 28 — these flags only keep an already-on screen on, they cannot wake the display from sleep on a modern Pixel.

Replaced with a transparent ScreenWakeActivity that uses setTurnScreenOn(true) / setShowWhenLocked(true), launched from the foreground monitoring service. Requires overlay permission (the existing dashboard hint already prompts for it; this PR extends it to also surface for KeepAwake-only configurations).

Behaviour: on connect, the screen wakes once. The device's normal display timeout takes over afterward. The CPU partial wakelock still keeps background work scheduled.

Companion to the earlier connect-pipeline timing fix.

Test plan

• ./gradlew assembleFossDebug
• ./gradlew testFossDebugUnitTest (541 tests pass; new tests cover wake ordering, overlay-permission gate, and the dashboard hint extension)
• ./gradlew lintVitalFossBeta lintVitalFossRelease
• Manual verification on a real device (Pixel 9 / Android 16): screen wakes when KeepAwake-enabled BT device connects from sleep

[d4rken]

Codex review pass — two issues caught and addressed in 5c5f824:

1. Overly broad BAL gate. wakeScreenNow() was checking !permissionHelper.canDrawOverlays() for every API >= 23, but BAL restrictions only apply from API 29+ (Android 10+). On Android 6-9, canDrawOverlays() returns false by default (SAW not granted), which made the wake silently no-op even though a transparent activity launch from a foreground service is permitted there without SAW. Fix: switched to the existing PermissionHelper.needsOverlayPermission() (hasApiLevel(Q) && !canDrawOverlays()), which matches the API gate already used by the dashboard hint.

2. Misleading hint copy for KeepAwake-only configurations. Title was "App launch permission" and message only mentioned launching apps / showing the home screen. Now: "Display over apps permission" and the message also mentions waking the screen on connect. English string only — translation keys unchanged, other locales pick up via the usual translation flow.

Test changes: switched the existing wake-screen mocks from canDrawOverlays to needsOverlayPermission (matches the new gate), tightened the setWakeLock(true) test to also assert idempotency, and added a regression guard wakeScreenNow gate uses needsOverlayPermission only that ensures a future revert to the broader canDrawOverlays check would fail. Test method names kept short to avoid retriggering the Robolectric tempdir flake fixed in ee87254.

Also clarified the wakeScreenNow log message from "Launched ScreenWakeActivity" to "Requested ScreenWakeActivity launch" — OS-level BAL denial may not throw, so the log only confirms the launch was requested, not that the screen actually woke.

[d4rken]

Update on the testGplay flake — investigated and dropped the flaky tests in 00fdd39.

The Robolectric tempdir setup for WakeLockManagerTest consistently fails on the testGplay CI job with NoSuchFileException creating eu.darken.bluemusic-dataDir under /tmp/robolectric-WakeLockManagerTest_xxx. The flake has been present since the file was first added in 94d387d — every CI run on this branch hit it. testFoss has consistently passed; testGplay has consistently failed. Tried: shorter test method names, single combined test method, plain-JVM rewrite using mockk Context. None of these stabilized testGplay.

Remaining test coverage is sufficient:

• KeepAwakeModuleTest (5 tests) verifies wakeLockManager.setWakeLock(true) and wakeScreenNow() are both invoked on Connected events, in the right order, before any reaction-delay would have completed.
• WakeLockManagerFieldsTest reflection-guards the screenWakeLock field removal.
• DashboardViewModelTest (4 tests) verifies the overlay-permission hint surfaces for keepAwake-only configs.

The intra-WakeLockManager assertions (CPU lock tag, Intent flags) that the deleted tests covered are visible by inspection in the small WakeLockManager.kt source itself.

If a future change wants to bring back Robolectric coverage here, the underlying tempdir issue should be debugged first — could be a gplay manifest size / parallel-test-fork interaction with Robolectric 4.14 that is independent of this PR.

[d4rken]

Codex follow-up brainstorm produced two polish items, both pushed in 5f218ab:

1. Skip wake when screen is on + unlocked. wakeScreenNow() now returns early if PowerManager.isInteractive() && !KeyguardManager.isKeyguardLocked. Prevents the unnecessary task-switch flicker when a user connects a Bluetooth device while their phone is already in active use. The wake still fires on the lockscreen so the launched app surfaces above the keyguard.

2. 60-second screen-hold after wake. ScreenWakeActivity now sets FLAG_KEEP_SCREEN_ON and finishes after 60s instead of immediately on onResume. Gives the user time to read the screen and tap the launched music app before the system display timeout fires. Touching the screen dismisses the activity early — the host app the user touched takes over screen-on responsibility from there. Activity death by timer / touch / memory-pressure all drop FLAG_KEEP_SCREEN_ON cleanly; nothing leaks. Hardcoded constant, no settings UI.

This is a slight semantic shift from the PR's original "wake once, normal display timeout" framing — closer to "wake briefly so the user can interact." Codex's brainstorm explored two heavier alternatives (long-lived transparent host with FLAG_KEEP_SCREEN_ON until disconnect; full-screen-intent notification) and recommended against both — the former is lifecycle-fragile and the latter is wrong-shape for this use case. The 60s hold was the bounded hybrid Codex thought struck the right balance.

Verified locally: 537 tests pass on both testFoss and testGplay; assembleFossDebug clean.