fix(vitest): resolve the quarantine runner with the current build's extension

[QuanticPotatoes]

Fixes #169.

Problem

MergifyReporter._configureRunner injects resolve(dir, 'runner.js') as the custom vitest runner, but the build (tsdown, format: ['esm', 'cjs']) only emits dist/runner.mjs and dist/runner.cjs — there is no runner.js in the published package. As soon as the quarantine list is non-empty (or flaky detection configures the runner), every worker dies with ERR_MODULE_NOT_FOUND before collecting a single test, aborting the entire suite.

We were hit by this in production CI on 2026-08-05: the first quarantine entry ever created on our repo flipped the latent path on and took down every vitest tier org-wide (0 tests collected, one collect error per file), on vitest 4.0.18 and 3.2.4 alike — not only 4.x as #169 reports. 0.3.1 is equally affected.

Why the existing tests didn't catch it

tests/runner.test.ts exercises the quarantine path end-to-end and passes — because it imports from ../src/reporter.js, so the injected path is src/runner.js, and vite-node remaps that .js specifier onto src/runner.ts. In the published package the injected dist/runner.js path goes through native node resolution in the worker, which does no such remapping.

Fix

Resolve the runner sibling with the same extension as the currently-executing module:

• dist/index.cjs → dist/runner.cjs
• dist/index.mjs → dist/runner.mjs
• src/reporter.ts (dev/tests) → src/runner.ts

One rule, correct in all three contexts, no behavior change in dev.

Regression test

Adds tests/dist-runner.test.ts: the same quarantine scenario as runner.test.ts, but importing MergifyReporter from ../dist/index.mjs — i.e. consuming the built artifact the way a real consumer does. It fails on main (expected 'failed' to be 'passed') and passes with the fix. (It requires pnpm build to have run before tests, which the workspace setup already does.)

Also verified from a standalone external project consuming the packed tarball: with the fix, the ERR_MODULE_NOT_FOUND crash is gone on vitest 4.0.18 and 4.1.8.

Side observation (out of scope here)

While validating from the standalone consumer (vitest 4.0.18 and 4.1.8, CLI runs), failure absorption did not engage even though the runner loaded and isQuarantined matched — whereas it works in this repo's own tests (vitest 4.1.7, programmatic startVitest). Possibly a separate vitest-version-sensitivity issue worth a look; happy to open a separate issue with the repro if useful.

[mergify]

Merge Protections

🔴 2 of 6 protections blocking · waiting on 👀 reviews and 🤖 CI

	Protection	Waiting on
🔴	Approval	👀 reviews
🟠	Continuous Integration	🤖 CI
🟢	Enforce conventional commit	—
🟢	🔎 Reviews	—
🟢	📕 PR description	—
🟢	🚦 Auto-queue	—

🔴 Approval

Waiting for

• #approved-reviews-by >= 2

This rule is failing.

• #approved-reviews-by >= 2

🟠 Continuous Integration

Waiting for

• check-success = all-greens

Waiting checks: all-greens.

• check-success = all-greens

---

Show 4 satisfied protections

🟢 Enforce conventional commit

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|internal|docs|style|refactor|perf|test|build|ci|chore|revert|ui)(?:\(.+\))?!?:

🟢 🔎 Reviews

• #changes-requested-reviews-by = 0
• #review-requested = 0
• #review-threads-unresolved = 0

🟢 📕 PR description

• body ~= (?ms:.{48,})

🟢 🚦 Auto-queue

When all merge protections are satisfied, this pull request will be queued automatically.