Fix launchctl bootstrap failures being discarded as XPC errors

[rogerneal]

Summary

• Surface launchctl bootstrap exit status and stderr from ServiceManager.register instead of continuing into a misleading apiserver XPC error.
• Keep container system start idempotent when the service is already registered.
• Add unit tests for domain selection helpers and a real launchctl failure path for error surfacing.

The system-domain bootstrap change for root outside Aqua is intentionally left to a follow-up PR so this half can merge on its own evidence.

Fixes #2008

Test plan

Tested

• swift test --filter ServiceManagerTests (5 tests, all passing after rebase)
• Real launchctl failure via ServiceManager.register with a missing plist; error includes launchctl bootstrap and status
• Local Aqua system start: register() loaded com.apple.container.apiserver and the process started

Not in this PR

• Root outside Aqua bootstrapping into the system domain (follow-up)
• Exact GitHub Actions macos-26 Background / non-login sudo container system start reproduction

[singhible]

Thanks for picking this up @rogerneal, and for being clear about what you did and
did not test. That made this easy to review.

I checked out f8d17d2 on macOS 26.5.2, Aqua session, non root. Your
ServiceManagerTests pass 7/7, PluginLoaderTest passes 12/12 twice in a row,
and swift format lint --strict is clean on both files. I could not reproduce the
non login root case either.

Three things I would raise:

The commit is unsigned. pr-build.yml runs a verify-signatures job that
fails on any unverified commit, so nothing can go green until that is fixed.

I would split the domain change out. The issue proposes two fixes, and this PR
does both. Surfacing the bootstrap failure is small and provable in any session
type. Bootstrapping into system moves where the services live, neither of us can
verify it, and it overlaps
#1514. Splitting lets the first
half merge on its own evidence instead of waiting for a macos-26 runner.

If the domain change stays, the rest of the code may not agree with it.
SystemStatus.swift:74 and SystemStop.swift:99 both call launchctl list
without a domain target, so they resolve against the calling process's launchd
context rather than the system domain you bootstrapped into. Your own idempotency
fallback goes through isRegistered, so it has the same question. If they do not
line up, a second system start throws instead of being a no op and
system status reports unregistered for a service that is running. Worth
confirming on the runner.

Two small ones while I am here: try isRegistered(...) inside the guard will
replace your good error message with a spawn error if launchctl cannot start, so
try? is safer, and LaunchPlist.CodingKeys.label.rawValue already exists
instead of the hardcoded "Label".

I think the core idea is okay, and it matches what enumerate() in the same type
already does.

[rogerneal]

@singhible Thanks for the careful review. I took your suggestions:

1. Commit is now signed and verified on GitHub.
2. Split out the system-domain change. This PR only surfaces bootstrap failures and keeps start idempotent.
3. Applied try? around isRegistered so a spawn failure cannot replace the bootstrap error, and switched the plist key lookup to LaunchPlist.CodingKeys.label.rawValue.

Follow-up for the domain half is coming next, including the SystemStatus / SystemStop / idempotency alignment you called out.