(test): wait on the real condition in the trace rotation tests

[devsuitup]

The flake

test/activity-trace.test.js failed intermittently in the full suite — one or two failures depending on the run — while passing 22/22 every time in isolation. Same family as the pre-commit hook that rejected a commit a few days ago and then went green on an immediate re-run.

A suite that lies intermittently invalidates every "CI is green" we exchange, so this was worth chasing to a proven root cause rather than a retry.

Root cause

Two hypotheses eliminated first, with evidence:

• Cross-file pollution via a singleton: ruled out. node --test on this install (v24.18.0) spawns a separate child process per test file — verified empirically, two probe files report different PIDs. No shared memory is possible.
• Shared scratch directory: ruled out by reading the code. Every test calls fs.mkdtempSync into a unique folder.

The actual cause: the three rotation tests waited on a fixed setTimeout instead of on the condition itself. pruneSegments() runs asynchronously from the stream.end() callback, and under the CPU and disk contention of the full suite that callback sometimes misses the fixed budget.

Worse than plain slowness, in "a failed prune is reported in the trace itself": t.close() ran after the fixed wait, and close() sets stream = null synchronously (activity-trace.js:194-198). When the still-pending prune callback then called trace('trace.prune-failed', …), the if (!stream && !write) return; guard at activity-trace.js:178 swallowed the line. Proven by temporary instrumentation of a copy of the module.

Searching for the same shape turned up a sibling: the base rotation test already polled, but with a 1000 ms budget that also proved too short under load (captured failing: 3 !== 2).

Fix

Test-only. activity-trace.js is untouched — the production behaviour was never wrong, the tests were measuring it badly.

The three fixed setTimeout waits become a waitUntil(check, {tries, intervalMs}) helper that polls the real condition (files on disk, array length, presence of the warning line) with a 10 s ceiling. In the failed-prune test the wait for the warning now happens before t.close(), removing the race with the pending callback.

Evidence it is fixed

• Before: 1–2 intermittent failures in the full suite; always green in isolation.
• After: 6 consecutive full runs — 671 tests, 664 pass, 7 skips, 0 fail every time — plus 5 consecutive isolated runs at 22/22.

One green run proves nothing about an intermittent test, hence the repeats.

eslint: 0 errors.

Reasoning written up in docs/activity-trace.md under "Testing the async prune path"; the code carries a one-line pointer.