app: fizzy times its own startup, and a handover's

[foxnne]

Part of plans/DASHBOARD_PLAN.md, "What performance work lacked": startup and handover phases. Stacked on #364 (it shares the report code); retarget to main once that merges.

What changes

fizzy times its own startup. core.profile.phase(io, name) stamps a moment of the app's start. fizzy stamps:

• at launch: main, lock (the single-instance lock), window (the backend up: GPU, fonts), editor, plugins, shown, and first frame;
• in an instance a restart's handover started (app: a restart hands the window over instead of closing it #356): lock deferred (handover), handover ready and handover lock.

Each run's first frame logs one line:

info: startup: up 1288 ms after main (window shown at 1198 ms)

The phases in the report: core.profile.report includes them with .startup = true, and they're published like Lookback and FrameCauses: their own data key, no change to the profiler's layout or abi. The new instance of a handover, read that way:

.startup = .{
    .{ .phase = "main", .ms = 0.0 },
    .{ .phase = "lock deferred (handover)", .ms = 0.4 },
    .{ .phase = "window", .ms = 151.6 },
    .{ .phase = "editor", .ms = 175.6 },
    .{ .phase = "plugins", .ms = 208.4 },
    .{ .phase = "handover ready", .ms = 211.7 },
    .{ .phase = "shown", .ms = 219.5 },
    .{ .phase = "handover lock", .ms = 232.1 },
    .{ .phase = "first frame", .ms = 301.9 },
},

It already shows something to act on: the window is shown about 80 ms before its first frame is drawn. That's true of every launch, and in a handover the new window covers the old one for those 80 ms before it has drawn anything. A follow-up can show it after the first frame.

Measuring a restart used to take a window sampler and a pid poller running outside fizzy, on macOS only.

SDK impact

• Core-only or additive: core.profile.phase, phases, Phases, ReportOptions.startup. No fingerprint move.

Verified

• macOS:
  • A cold launch: the startup line above.
  • A handover: the table above, read from the new instance through the agent plugin. That used a local build of it against this tree; the agent's own tool for this waits for the SDK release, since it's pinned to 0.2.22.
  • The first version of this crashed at main: the clock went through dvui.io, which the backend hadn't set yet. So phase takes the io.
  • Gates: zig build, zig build test (533/534, 1 skipped), test-integration (375/375), check-web, test-sdk-version.
• Windows, Linux: CI.

Follow-ups

• Show a window after its first frame is drawn, not before, starting with a handover's.
• The real process start (macOS proc_pidinfo, Windows GetProcessTimes, Linux /proc/self/stat), so main isn't time zero and dyld and static initialisation are counted.
• The agent's fizzy_build on fizzy's repo reports the new instance's phases, once the SDK is released and the agent repinned.

🤖 Generated with Claude Code