Auto-detected flaky tests (merge-group) — review for quarantine

[github-actions]

Flaky-test detection (issue #1782) found the following candidates
for quarantine during a merge-group CI run:

tests/unit/commands/promote-registration.test.ts
tests/unit/services/evidence-summary-adversarial.test.ts
tests/unit/utils/bun-compat-exit-first-2530.test.ts

To quarantine: append each line to the appropriate
scripts/ci/quarantined-tests*.txt file.

This issue was filed automatically by the flake-detection workflow.

[zaxbysauce]

This issue was filed automatically by the flake-detection workflow described in #1782: scripts/ci/detect-and-quarantine-flakes.sh extracts ::notice/::error file annotations from the merge-group run, drops anything already quarantined or matching infra-failure signatures, and files a tracking issue with exactly this title and body — so the three paths listed are genuine new candidates, not repeats of existing ledger entries (scripts/ci/quarantined-tests.txt currently has no active entries, and none of the three files appear in any of the four ledgers).

Before quarantining, two repo rules apply:

1. Metadata is mandatory. A bare append is not enough — per [Workstream C] PR 01 of 09: Root-fix filesystem, process, and test-isolation flakes #2477, every active entry in quarantined-tests*.txt must carry # OWNER: and # EXPIRY: comment lines (enforced by Check 7 in scripts/check-invariants.ts, with a 14-day post-expiry grace window). An entry without metadata will fail check:invariants.

2. Prefer root-cause over quarantine. Per the testing skill docs, quarantine is for genuine pre-existing failures unrelated to recent changes. The strongest lead here is tests/unit/utils/bun-compat-exit-first-2530.test.ts, which shells out to bun build plus a node probe with a 5-second timeout — a pattern that is sensitive to runner load and can look flaky on merge-group runners without being a real product defect. promote-registration.test.ts and evidence-summary-adversarial.test.ts have no obvious timing hazard from a static read.

Suggested handling: rerun the three files in isolation (and check the flake-suggestions.txt artifact from the triggering run for the actual failure annotations), then either fix the root cause or quarantine with proper OWNER/EXPIRY metadata in a single small PR. Also note this is one of many near-identical auto-issues (2730, 2718, 2719, 2721, 2743, ...); if the same files keep resurfacing across runs, consider consolidating them into one tracking issue and linking the CI artifact, so the ledger history stays reviewable.