test(fresh-baseline): stop asserting a measured duration is exactly 0

[myselfsiddharth]

Summary

tests/unit/fresh-baseline-runner.test.ts had a load-dependent flake. It surfaced as a red CI on #186 (@anthropic-ai/sdk 0.117.1 → 0.122.0), which is innocent — that PR is fine to merge once this lands.

The StubFreshBaselineClient case asserted:

expect(result.cost_fresh).toEqual({ tokens_in: 0, tokens_out: 0, wall_clock_ms: 0 });

The stub returns normally rather than throwing, so it takes FreshBaselineRunner's measured path (measureWallClock, src/runner/fresh-baseline-runner.ts:120) — not the forced-zeroCost() catch at :136-143. So wall_clock_ms is real elapsed time. Asserting it equals 0 asserts the machine was fast, not that the code was honest.

Evidence

Condition	Result
#186's branch (SDK 0.122.0) locally, idle	11/11 pass — SDK is not the cause
Unmodified main, idle, 12 runs	0 failures — my machine rounds to 0
Unmodified main, 12-way CPU saturation, 10 runs	1 failure — reproduced
This branch, same saturation, 12 runs	0 failures

What the test still defends

The claim is "never a silent success," so tokens are still pinned to exactly 0 and task_success to false. Only the duration assertion is relaxed — to non-negative and finite, which is the real invariant for a measured value.

Deliberately not changed

The three sibling wall_clock_ms: 0 assertions (lines 134, 140, 163) are left alone. Those cases throw, so zeroCost() makes 0 a genuine forced invariant rather than a timing accident. Relaxing them would weaken real coverage.