helper status reports "Service enabled: no" when the platform stores the accessibility component in flattened form

### Summary

`artemis helper status` reports `Service enabled: no` (and `Service answering: no`) while the
helper service is in fact enabled, bound and being used. The check compares the accessibility
component name against a single notation, and the platform may store the other one.

### Observed

On Android 11, same device and moment where the service is bound and a running task reports
`hierarchy_backend: helper`:

```
$ artemis helper status --serial
│ Installed version │ 6 / 7 (installed) │
│ Service enabled │ no │
│ Tunnel │ none │
│ Service answering │ no │

$ adb shell settings get secure enabled_accessibility_services
com.ayaneo.home/com.ayaneo.gamewindow.service.WindowKeyEventService:com.x8bit.bitwarden/com.x8bit.bitwarden.Accessibility.AccessibilityService:com.artemis.helper/com.artemis.helper.ArtemisAccessibilityService

$ adb shell settings get secure accessibility_enabled
1

$ adb shell dumpsys accessibility | grep -A 4 "Bound services"
Bound services:{… Service[label=Artemis Accessibility Hel…, capabilities=161, …]}
Binding services:{}
```

The platform rewrote the entry in its flattened form
(`com.artemis.helper/com.artemis.helper.ArtemisAccessibilityService`), not the short form.

On Android 17 the stored entry keeps the short form and the check passes.

### Cause

`artemis/runtime/helper_manager.py`:

```python
SERVICE_NAME = f"{PACKAGE_NAME}/.ArtemisAccessibilityService" # com.artemis.helper/.ArtemisAccessibilityService

def is_service_enabled(self, serial: str) -> bool:
…
return SERVICE_NAME in enabled.split(":") if enabled and enabled != "null" else False
```

Strict string equality against the `:`-split entries. The platform's flattened notation
(`pkg/pkg.Class`) never matches the short notation (`pkg/.Class`), so the check returns `False`
and the status/readiness layers report the helper as disabled although the system considers it
enabled and binds it.

### Verification

`adb shell settings put secure enabled_accessibility_services /.ArtemisAccessibilityService`
is accepted, then the platform stores it back in flattened form on this device:

```
$ adb shell settings put secure enabled_accessibility_services "…:com.artemis.helper/.ArtemisAccessibilityService"
$ adb shell settings get secure enabled_accessibility_services
…:com.artemis.helper/com.artemis.helper.ArtemisAccessibilityService
```

i.e. both notations designate the same `ComponentName`, and only the notation differs.

### Proposed fix

Normalise before comparing: accept both `pkg/.Class` and `pkg/pkg.Class` (e.g. compare package
plus class separately, or expand the short form to its fully qualified name before the equality
test).

Start in artemis/runtime/helper_manager.py at SERVICE_NAME and is_service_enabled, then reproduce the status check with the shown adb settings output. Done means the helper is reported as enabled and answering when enabled_accessibility_services contains either the short or flattened component notation.

Written by the indexing model from the issue text.