feat(core): enhance startup profiling

[sehoon38]

Summary

This PR enhances startup profiling by adding cross-process timing and UI milestones to the core package. This will help in identifying bottlenecks during the CLI's initialization phase.

Details

• Integrated cross-process timing to capture milestones from both the CLI and core packages.
• Added UI milestones to track when specific interface elements are rendered.

Related Issues

Related to #21259

How to Validate

1. Run npm run debug to see the startup profiling output.
2. Verify that UI milestones and cross-process timings are correctly logged.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on MacOS
  • npm run
  • npx
  • Docker
  • Podman
  • Seatbelt

[gemini-cli]

Hi @sehoon38, thank you so much for your contribution to Gemini CLI! We really appreciate the time and effort you've put into this.

We're making some updates to our contribution process to improve how we track and review changes. Please take a moment to review our recent discussion post: Improving Our Contribution Process & Introducing New Guidelines.

Key Update: Starting January 26, 2026, the Gemini CLI project will require all pull requests to be associated with an existing issue. Any pull requests not linked to an issue by that date will be automatically closed.

Thank you for your understanding and for being a part of our community!

[github-actions]

Size Change: +3.3 kB (+0.01%)

Total Size: 26 MB

Filename	Size	Change
./bundle/gemini.js	25.5 MB	+3.3 kB (+0.01%)

ℹ️ View Unchanged

Filename	Size
./bundle/node_modules/@google/gemini-cli-devtools/dist/client/main.js	221 kB
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/_client-assets.js	227 kB
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/index.js	11.5 kB
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/types.js	132 B
./bundle/sandbox-macos-permissive-open.sb	890 B
./bundle/sandbox-macos-permissive-proxied.sb	1.31 kB
./bundle/sandbox-macos-restrictive-open.sb	3.36 kB
./bundle/sandbox-macos-restrictive-proxied.sb	3.56 kB
./bundle/sandbox-macos-strict-open.sb	4.82 kB
./bundle/sandbox-macos-strict-proxied.sb	5.02 kB

_{compressed-size-action}

[mananpatni]

I've been working on the Idea 5 performance dashboard for GSoC, and this PR directly affects how the PerformanceAggregator would consume startup phase data.

One thing I noticed: for cross-process phases where relativeStart can be negative, performance.measure() clamps start to Math.max(0, relativeStart) to avoid ERR_PERFORMANCE_INVALID_TIMESTAMP. The real duration is correctly preserved in phase.durationMs, and flush() uses phase.durationMs ?? measure.duration. But any code that reads performance.getEntriesByType('measure') directly would get a shorter-than-real duration for those phases.

For the /perf dashboard, I'd need the accurate phase durations. Would it make sense to expose a read-only accessor on StartupProfiler for completed phase results — something like getPhaseResults() returning the same data that flush() assembles in the startupPhases array (around the block starting at the for loop over this.phases.values())? That way consumers don't need to go through performance.getEntriesByType('measure') and can avoid the clamping discrepancy.