refactor(desktop): startup task registry

Problem

runtime-host-boot.ts is a ~2,290-line side-effect module whose startup work is ordered by implicit top-level awaits and scattered void-backgrounded promises (guest mounts, remote-access recovery, profile autostart, MCP readiness, settings effects). Ordering constraints live only in comments — #1316 deliberately resolves login-shell PATH before any store, tool, or child-process spawn — so a new startup task has no declared place to go, and an accidental reordering is only caught by runtime symptoms. The module keeps accreting: recent features (managed artifact preview, browser IPC wiring) added more awaits and quit hooks to the same file.

Desired outcome

Startup work registers as tasks with declared phases and dependencies, and the runner derives scheduling from the graph:

• tasks without an ordering edge may run concurrently,
• work not needed before the first frame can defer itself there,
• hard constraints — single-instance lock and userData isolation first; login-shell PATH resolved before any child-process spawn (#1316) — are enforced edges in the declared graph rather than comment conventions.

#5296 already centralized startup-time value resolution (revealMode in startup-context.ts); this extends the same direction from values to tasks.

Non-goals

• Weakening any existing mandatory ordering (lock/userData first; #1316 PATH-before-spawn).
• Behavior-changing parallelism or deferral without measurement: land the registry reproducing today's effective ordering first, then flip scheduling as a separately measured change.
• The module-top sequence in main.ts — dev/prod userData isolation, single-instance lock, dynamic import — is unchanged.

Acceptance

• Phase/dependency registry exists; existing boot steps registered with phases and deps
• #1316's PATH constraint encoded as a declared edge
• Effective startup ordering unchanged (same-sequence test)
• Follow-up: dependency-permitted concurrency/deferral landed as a separately measured change

Related work

• #1316 — the PATH-before-spawn constraint any scheduling must preserve
• #5296 — centralized startup-context values; precedent for this consolidation
• #2913 — the startup data-flow wait ("startup waits for the complete snapshot before mounting React") is complementary and can later land on the same scheduler