perf: move AgentBootstrapService to Phase.Background and parallelize init

[DeJeune]

What this PR does

Before this PR:
AgentBootstrapService ran in Phase.WhenReady with a sequential initialization chain (~4.4s), blocking other WhenReady services and delaying UI startup.

After this PR:

• Moved to Phase.Background (fire-and-forget, never blocks other phases)
• Removed unnecessary @DependsOn(['ApiServerService']) — none of the bootstrap operations use ApiServerService
• Parallelized bootstrapBuiltinAgents, restoreSchedulers, and channelManager.start via Promise.all
• Parallelized channel adapter connections in ChannelManager.start() (was sequential for...await)

Why we need it and why it was done in this way

The following tradeoffs were made:

• All three bootstrap operations are idempotent, self-contained, and non-critical for UI rendering, so Phase.Background is the correct lifecycle phase per the Phase Selection Guide.

The following alternatives were considered:

• Keeping Phase.WhenReady with manual fire-and-forget (this.initDone = Promise.all(...) without await) — rejected because it reimplements what Phase.Background already provides natively.
• Parallelizing initCherryClaw and initCherryAssistant inside bootstrapBuiltinAgents — not done due to documented SQLITE_BUSY risk from concurrent writes.

Breaking changes

None. All changes are internal to the main process startup sequence.

Special notes for your reviewer

• registerSessionStreamIpc() is synchronous (just registers ipcMain.handle calls) — no await needed.
• ipcMain registration works in Phase.Background since it doesn't require Electron's app to be ready.
• Channel adapters already handle their own errors in connectChannelFromRow, so Promise.all won't short-circuit on a single adapter failure.

Checklist

• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior.
• Self-review: I have reviewed my own code (e.g., via /gh-pr-review, gh pr diff, or GitHub UI) before requesting review from others

Release note

NONE