Accessibility helper cannot be enabled on Android 11: fresh install stays in the stopped state and the package has no launchable component

### Summary

On Android 11 (SDK 30) the accessibility helper can never be enabled. The APK declares no
launchable component, so a fresh install stays in the platform `stopped` state, and the
accessibility framework refuses to bind a service of a stopped package. The same APK binds
immediately on Android 17 (SDK 37).

### Observed

Device A: Android 17, SDK 37 — works. Device B: Android 11, SDK 30 — never binds.
Same APK (`com.artemis.helper` v1.2.0, version code 6), installed fresh on both, service
enabled the same way (`settings put secure enabled_accessibility_services …` + `accessibility_enabled 1`).

On device B, after `artemis helper install --serial `:

```
$ adb shell dumpsys package com.artemis.helper | grep -o "stopped=[a-z]*"
stopped=true

$ adb shell dumpsys accessibility | grep -E "Bound services|Binding services|Crashed"
Bound services:{Service[label=AYAHome, …], Service[label=Bitwarden, …]}
Binding services:{{com.artemis.helper/com.artemis.helper.ArtemisAccessibilityService}}
Crashed services:{}

$ adb shell ps -A | grep artemis # no output: no process
$ adb shell settings get secure enabled_accessibility_services
…:com.artemis.helper/com.artemis.helper.ArtemisAccessibilityService
$ adb shell settings get secure accessibility_enabled
1
```

The service stays in `Binding services` indefinitely and never reaches `Bound services`.

On device A, identical sequence:

```
$ adb shell dumpsys package com.artemis.helper | grep -o "stopped=[a-z]*"
stopped=false
$ adb shell ps -A | grep artemis
u0_a467 11157 … com.artemis.helper
```

### Cause

The helper manifest declares only a service and a receiver; there is no activity:

```
$ adb shell cmd package resolve-activity --brief -c android.intent.category.LAUNCHER com.artemis.helper
No activity found
```

A freshly installed package is in the `stopped` state until one of its components is launched.
With no launchable component, nothing can clear it, so the package stays stopped and the
accessibility service cannot be bound. Android 17 starts the app when its accessibility service
is enabled, which is why the same APK works there.

### Verification

Rebuilding the same source with a minimal `MAIN`/`LAUNCHER` activity, installing it and
launching it once clears the flag and the service binds:

```
$ adb shell install -r ArtemisAccessibilityHelper.apk
Success
$ adb shell am start -n com.artemis.helper/.LauncherActivity
Starting: Intent { cmp=com.artemis.helper/.LauncherActivity }
$ adb shell dumpsys package com.artemis.helper | grep -o "stopped=[a-z]*"
stopped=false
$ adb shell dumpsys accessibility | grep -A 3 "Bound services"
Bound services:{… Service[label=Artemis Accessibility Hel…, capabilities=161, …]}
Binding services:{}
```

A task then runs on the helper instead of UIAutomator2:
`hierarchy_backend: helper` / `UI hierarchy source: the Artemis accessibility helper`.

### Proposed fix

Declare a minimal launcher activity in the helper manifest and start it once at the end of
`helper install` (`am start -n com.artemis.helper/.LauncherActivity`). Launching any component
clears the `stopped` state, on every Android version.

Steps that do NOT clear the flag on Android 11, for reference: explicit broadcast to
`.TokenReceiver`, `am startservice` (rejected, requires `BIND_ACCESSIBILITY_SERVICE`),
`pm disable-user` + `pm enable`, `adb install -r`, `artemis helper install` (reports
`up_to_date`), and toggling the service off/on from the Accessibility settings UI.

Start with the helper manifest and the implementation of `artemis helper install`; inspect how `ArtemisAccessibilityService`, `TokenReceiver`, and the proposed `LauncherActivity` are declared and invoked. Reproduce the fresh-install flow on Android 11, then verify that launching the component clears the stopped state and the accessibility service reaches Bound services.

Written by the indexing model from the issue text.