bug(service): kickstart newly bootstrapped LaunchAgents #1479

Describe the bug

On macOS, powercontext service install and the restart path can register the per-user LaunchAgent successfully but leave the Server process stopped. The controller then waits for the HTTP endpoint until it times out, even though no Server process was started.

LaunchdUserAdapter.start() currently treats a successful launchctl bootstrap as an immediate start. bootstrap registers the job; launchctl kickstart is the operation that explicitly asks launchd to run it immediately. Relying only on RunAtLoad and KeepAlive makes the existing start contract nondeterministic.

This has appeared repeatedly in the native macOS lifecycle CI, both during the initial install and after an explicit stop/start:

• https://github.com/oceanbase/powercontext/actions/runs/34075169684/job/101599749920
• https://github.com/oceanbase/powercontext/actions/runs/33935919038
• https://github.com/oceanbase/powercontext/actions/runs/33865926348

The same #1459 commit passed the same runner image shortly before the latest failure, which rules out a DSH behavior regression and points to this launchd start race.

Steps to reproduce

1. On macOS, ensure the PowerContext LaunchAgent is not loaded.
2. Run powercontext service install, or stop an installed service and start it again.
3. Observe the native lifecycle until the configured local HTTP endpoint becomes live.
4. On affected runs, launchctl bootstrap returns successfully but the endpoint never becomes reachable and the service produces no startup logs.

The repository's tests/native/test_personal_service_lifecycle.py::test_native_personal_service_lifecycle exercises both paths and has reproduced the failure intermittently in CI.

Expected behavior

A successful install or explicit start must ask launchd to start the registered job immediately. If launchd rejects the start, the command should surface that error directly instead of waiting for an HTTP timeout.

Actual behavior

A newly bootstrapped job is not explicitly kickstarted. Some runs remain registered without a running process until the controller reports that the service did not become live. In the initial-install failure, both Server stdout and stderr logs are empty because the process never starts.

Environment

• PowerContext: current master and PR fix(dsh): complete automatic-path diagnostics and recall presentation #1459 merge commit
• Python: 3.13 in native-service CI
• OS: macOS 26.6.2 arm64, GitHub Actions image 20260831.0337.3

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.