test(paths): telemetry.test.ts flakes under the parallel test runner — two different tests failed on the same unmodified checkout

Summary

packages/paths/src/telemetry.test.ts fails intermittently when the suite runs under bun run test / bun run validate, which execute all ten package suites in parallel. It passes reliably when the @archon/paths suite runs on its own. Two different tests in the file failed across two runs of the same unmodified checkout, which is what rules out a code cause and points at the flush.

Reproduction

git checkout dev          # e237584d, unmodified
bun run test

Observed on dev with no local changes:

@archon/paths:test | (fail) new capture functions are fire-and-forget no-throw >
                   |        captureWorkflowCompleted serializes cache totals with schema version 6 [101ms]
@archon/paths:test | 311 pass, 1 fail

A second run of the identical checkout failed a different test in the same file:

@archon/paths:test | (fail) new capture functions are fire-and-forget no-throw >
                   |        captureArchonStarted serializes deployment shape to wire properties (enabled) [87ms]
                   |        error: expect(received).toBeDefined() — Received: undefined
                   |        at packages/paths/src/telemetry.test.ts:672

Serially it is green every time:

bun run --filter @archon/paths test
→ 312 pass, 0 fail   (670ms)

Note the runtime difference: the same 12 files take 670ms serially and ~5.3s under the parallel runner — roughly 8x, i.e. the suite is running under heavy CPU contention when it fails.

Expected behavior

telemetry.test.ts passes deterministically regardless of machine load or how many package suites run concurrently.

Actual behavior

A test asserts on events captured from a fetch spy after await shutdownTelemetry(), and under load the expected event is absent from the decoded /batch/ bodies — so events.find(...) returns undefined and the assertion fails. The affected tests share the shape:

captureX({...});
await shutdownTelemetry();
// ... gunzip the captured bodies, then:
const ev = events.find(e => e.event === 'archon_started');
expect(ev).toBeDefined();

The file comments this pattern as flushing "deterministically before restoring (no flaky timers / real ingest)" (telemetry.test.ts:468), but the evidence says shutdownTelemetry()'s flush does not in fact guarantee every queued event has been handed to fetch before it resolves — posthog-node batches internally, and under contention the batch has not been posted when the assertion runs.

Why it matters

This is the failure mode #3290 is about: it only surfaces in the PR-gating parallel job, so contributors see a red suite that they cannot reproduce locally and that has nothing to do with their change. It also masks real failures, since the runner SIGINTs the other nine suites as soon as one package exits non-zero — a single flake aborts the whole run.

Suggested direction

Either make shutdownTelemetry() genuinely await the in-flight batch post before resolving, or have these tests await the spy observing the expected event rather than assuming the flush already delivered it. Not proposing a specific fix — the owner of the telemetry flush contract should decide which half is wrong.

Environment

• bun test v1.3.9 (cf6cdbbb), Linux x64
• dev @ e237584d