refactor: simplify waterfall timeline duration computation

[hoootan]

Summary

• Sort steps once by started_at, filter out steps without timestamps
• Compute timeline span from first-to-last step start (simpler than computeStepSpan)
• Infer step duration from gap to next step for legacy data; use real duration (>500ms) for SDK-fixed data
• Remove now/runStartedAt props — timeline is self-contained from step data
• Cleaner render loop using sorted array index for duration lookup

Test plan

• Waterfall renders correctly for old runs (legacy started_at == ended_at)
• Waterfall renders correctly for new runs (SDK timing)
• Steps without started_at are excluded (pending steps don't break layout)
• Expand/collapse still works with >15 steps

[Copilot]

Pull request overview

Refactors the Execution Timeline (waterfall) rendering on the run detail page to simplify how step ordering, timeline span, and per-step bar durations are computed directly from step timestamps.

Changes:

• Sorts steps once by started_at and filters out steps without timestamps.
• Replaces computeStepSpan + per-step duration map with an index-based duration array derived from gaps to the next step (and recorded durations when available).
• Removes runStartedAt/now props from WaterfallTimeline and simplifies the render loop.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

timelineSpan is computed from first step start → last step start, but bar widths use stepDurations that can extend past lastStart (e.g. SDK-fixed steps with real ended_at, or a long-running last step). This makes the axis labels inaccurate and forces late/long steps to be artificially clamped. Consider computing the span end from the max effective end time (e.g. max(start + computedDuration) or max(ended_at/now)), then deriving timelineSpan from that.

[Copilot]

The selfDuration > 500 heuristic will treat legitimately short SDK-fixed steps (<500ms) as “legacy” and infer their duration from the next step gap, which can significantly overstate timing. A more reliable legacy check is to detect near-equal started_at/ended_at (as before) rather than using an absolute 500ms threshold.

Suggested change

	// For each step, compute duration as gap to next step (legacy fix)
	// This works because all existing data has started_at ≈ ended_at (useless),
	// but the started_at values between steps reflect real execution timing.
	const stepDurations: number[] = sorted.map((step, i) => {
	const start = new Date(step.started_at!).getTime();
	const end = step.ended_at ? new Date(step.ended_at).getTime() : Date.now();
	const selfDuration = end - start;
	// If step has real duration (> 500ms), use it (future SDK-fixed data)
	if (selfDuration > 500) return selfDuration;
	// Otherwise, infer from gap to next step
	// For each step, compute duration as gap to next step only for legacy data
	// where started_at and ended_at are effectively identical. For SDK-fixed
	// data, always use the actual recorded duration, even if it is short.
	const stepDurations: number[] = sorted.map((step, i) => {
	const start = new Date(step.started_at!).getTime();
	const end = step.ended_at ? new Date(step.ended_at).getTime() : Date.now();
	const selfDuration = end - start;
	const isLegacyDuration = step.ended_at && Math.abs(selfDuration) <= 1;
	// Use recorded duration for non-legacy data, including legitimately short steps.
	if (!isLegacyDuration) return Math.max(selfDuration, 0);
	// Legacy data: infer from gap to next step

[Copilot]

totalDuration is now unused in WaterfallTimeline, and removing the computeStepSpan(...) call leaves computeStepSpan unused as well. With @typescript-eslint/no-unused-vars enabled (warn), this will introduce lint warnings; consider deleting the unused helper and dropping totalDuration from the component props and call sites.