fix: pick busiest CPU profile from multi-thread traces

[TMisiukiewicz]

Explanation of Change

Chrome Performance traces can hold more than one CPU profile, one for each JS thread that was recording (main renderer, other tabs, service workers). Tracesift keeps only one of them, and it picked the profile with the most samples.

An idle thread can easily have the most samples. In the trace that exposed this, the service worker had 100k samples, but almost all of them were (idle), so it beat the main renderer profile (41k nodes of real app work, 60k samples). The analysis then ran on a profile with nothing in it.

This change ranks profiles by the number of samples that are not (idle), so the thread that actually did work gets analyzed.

Tests

1. Record a Chrome Performance trace of a web app that has an active service worker (or another tab/renderer recording at the same time), so the trace contains several Profile/ProfileChunk groups.
2. Upload the trace to tracesift.
3. Verify that the hotspots and bottlenecks come from the app's main thread code, not a near-empty profile made of (idle)/(program).
4. Upload a single-profile .cpuprofile and a Hermes trace and verify that both still analyze the same as before.

• npm test, typecheck and lint pass

🤖 Generated with Claude Code

[hurali97]

Thanks 🚀