[Bug]: flaky test — lineage-and-scan-cache-part-03 worktree scan-cache TTL assertion is order/timing dependent #22579

Summary

src/main/runtime/orca-runtime-tests/lineage-and-scan-cache-part-03.spec.ts:353 fails intermittently in CI with a call-count mismatch:

AssertionError: expected "vi.fn()" to be called 3 times, but got 4 times
AssertionError: expected "vi.fn()" to be called 3 times, but got 5 times

Both variants observed. It runs in the tests node 24 8/8 shard (and has also surfaced via 1/8).

The assertion

await runtime.listDetectedManagedWorktrees('id:repo-a')
await vi.advanceTimersByTimeAsync(10_000)
await runtime.listDetectedManagedWorktrees('id:repo-b')
await vi.advanceTimersByTimeAsync(20_000)
await runtime.listDetectedManagedWorktrees('id:repo-a')
await runtime.listDetectedManagedWorktrees('id:repo-b')

expect(listWorktrees).toHaveBeenCalledTimes(3)

It pins a scan-cache TTL using fake timers. Getting more calls than expected is consistent with cache entries expiring when they shouldn't — i.e. something other than the faked clock influencing TTL, or state leaking between files in the shard.

Impact

It is not tied to any particular change. I hit it across four unrelated OpenCode PRs (#22444, #22544, #22546, #22547) over a few hours; each time it cleared on a plain rerun with no code change. Because it also fails the aggregate verify check, every hit looks like a red PR and costs a diagnosis cycle before you can conclude it is noise.

Passes consistently locally: pnpm test src/main/runtime/orca-runtime.test.ts → 1294–1298 passed.

Suggested direction

Worth checking whether the runtime's scan cache reads wall-clock time (Date.now() captured outside the faked context, or a timer created before vi.useFakeTimers()) rather than the faked clock, and whether the cache is module-scoped and therefore shared with other spec files in the same shard.

Filed rather than fixed because the fix depends on how listDetectedManagedWorktrees's cache is meant to be scoped, which the runtime owners will know.