fix: ignore stale substep timestamps when computing target compilation duration

[fortmarek]

Summary

addCompilationTimesToTarget (and addCompilationTimesToApp) currently subtract target.startTimestamp from the latest substep's compilationEndTimestamp. For incremental Xcode builds this can produce a negative compilationDuration because Xcode reuses substep entries from prior build sessions for files that didn't need recompilation. Those substeps keep their original (older) timestamps and are not flagged wasFetchedFromCache, so the existing filter doesn't exclude them, and the chosen "last compile substep" can have ended long before the target started.

This PR filters those stale substeps out by also requiring compilationEndTimestamp >= parent.startTimestamp.

Concrete example

A real .xcactivitylog from an incremental build (404 targets, ~52s wall clock, only one target's sources had changed):

	Before	After
Targets with negative compilationDuration	364 / 404	0 / 404
Targets with zero	39	403
Targets with positive	1 (0.41s)	1 (0.41s)

The single target with positive duration was the only one with source changes requiring real compilation; the rest correctly report 0. Without the fix, those 403 targets each report values around -1118s, which downstream consumers (e.g. systems storing compilationDuration as an unsigned integer) wrap into nonsensical huge numbers.

Test plan

• Added testParseTargetCompilationTimesIgnoresStaleSubsteps covering a target whose only substep ended before the target started; expects compilationDuration == 0 and compilationEndTimestamp == startTimestamp.
• Existing testParseTargetCompilationTimes, testParseAppCompilationTimes, and testParseAppNoopCompilationTimes still pass.
• Re-parsed an affected real-world .xcactivitylog and confirmed all compilationDuration values are non-negative.

🤖 Generated with Claude Code