Delay accessibility service init until user unlock

[smh786]

Summary

Delay KeyMapper accessibility-service controller initialization until Android reports that the user is unlocked.

When the accessibility service is started during Direct Boot, it can currently construct the controller/dependency graph and attempt to open the normal Room database under credential-encrypted storage:

/data/user/0/io.github.sds100.keymapper/databases/key_map_database

Before the first unlock after boot, that storage is not available, so the service can crash/restart repeatedly.

This change keeps the accessibility service connected but inert while UserManager.isUserUnlocked == false. It does not create the controller until the user is unlocked. After unlock, the controller is initialized lazily from onServiceConnected, onAccessibilityEvent, or onKeyEvent.

Reproduction

Tested on a Zinwa Q25 running BenOS Uma.1.

Installed KeyMapper 4.2.0-foss from the latest GitHub release over the ROM-provided 3.2.1-foss system app, with KeyMapper Accessibility enabled and no external workaround app installed.

After reboot, before first unlock:

User 0: RUNNING_LOCKED
enabled_accessibility_services includes:
io.github.sds100.keymapper/io.github.sds100.keymapper.system.accessibility.MyAccessibilityService

Logcat shows KeyMapper starting its accessibility service and then trying to open CE storage:

Start proc ... io.github.sds100.keymapper ... MyAccessibilityService
Failed to ensure /data/user/0/io.github.sds100.keymapper/databases: mkdir failed: errno 126 (Required key not available)
SQLiteCantOpenDatabaseException: Cannot open database '/data/user/0/io.github.sds100.keymapper/databases/key_map_database'
Directory /data/user/0/io.github.sds100.keymapper/databases doesn't exist

On this device, the repeated Direct Boot crash/restart state appears to corrupt lockscreen physical-keyboard handling until the first unlock. Examples observed before first unlock:

• Harpocrat Keyboard typed letters as uppercase.
• Gboard/other keyboards duplicated characters.
• adb shell getevent -lt showed only one hardware key down/up event, so duplication occurred above the Linux input layer.

After first unlock, KeyMapper works normally again.

Notes

The app and IME paths already contain UserManager.isUserUnlocked handling. This applies the same Direct Boot boundary to the accessibility service path.

Local verification

• Confirmed the bug still reproduces on KeyMapper 4.2.0-foss before this patch.
• Local Windows Gradle compile was blocked by an unrelated generated AIDL source issue where a Windows path containing \Users is emitted into a Java comment and parsed as an illegal unicode escape. I could not complete a local compile in this workspace, so CI should be treated as the compile authority for this PR.