fix(mcp): do not await startup lifecycle snapshot on critical path

[Pitchfork-and-Torch]

Summary

Fixes #461.

After the stdio transport is up, startMcpServer() was still awaiting lifecycle.getSnapshot() before the server could settle into answering the first tools/list. That snapshot work (simulator os_log session enumeration, peer process sample, etc.) is telemetry-only and was delaying the first tools/list by ~10–17s on cold start. Short health-probe clients (e.g. Claude Code claude mcp list) then report Connected · tools fetch failed even though the server is healthy.

Change

Move the startup snapshot off the critical path:

• Fire-and-forget lifecycle.getSnapshot() with the same start metrics / anomaly logging
• Skip logging if shutdown was already requested
• Surface snapshot failures as warnings (same spirit as deferred bootstrap)

This matches the existing deferred-initialization pattern immediately below the old await.

Why not delete the snapshot

The issue asks to keep the telemetry; only readiness should not block on it. Metrics and anomaly warnings still run asynchronously.

Test plan

• xcodebuildmcp mcp over stdio: initialize then immediate tools/list should return without the multi-second cold-start stall
• Confirm [mcp-lifecycle] start … still appears in logs shortly after startup
• In-session tools (list_sims, etc.) still work
• Startup anomaly warnings (if any) still log

Notes

• Cannot fully re-time simulator enumeration on this contributor environment; logic change matches the issue’s verified root cause and suggested fix.
• Minimal one-file change.

[Pitchfork-and-Torch]

Pushed a follow-up commit that pins start metrics/anomaly phase to the schedule-time running phase (captured before fire-and-forget getSnapshot()), so deferred snapshot logging is not attributed to deferred-initialization if markPhase advances first.

Addresses the Sentry review note on phase race.