Run npm test in CI, and give main.js a testable seam for child-process logic

[juanmaguitar]

Two gaps surfaced while working on #38. Neither blocks that PR, but together they mean platform-specific bugs can only be found by hand.

1. npm test runs in no CI step

.buildkite/pipeline.yml has three steps — Windows, macOS, Linux — and all three only build and verify signing. None of them runs the test suite, so the 25 existing tests (azure-sign, patch, npm-runner, npm-install.integration) protect nothing automatically; they only run when someone remembers to type npm test.

Adding it to the Windows step in particular would pay for itself immediately. Several things this app depends on are platform-specific and currently verified on macOS only:

• the node/npm/npx PATH shims in ensureNodeShimDir(), including the .cmd/.bat variants and the STATUS_DLL_NOT_FOUND workaround
• npm config precedence (an env var overriding a project .npmrc)
• npm's error wording, which Retry npm install with relaxed engine checks when a dependency demands a newer Node #38's retry detection matches against

test/npm-install.integration.test.cjs (added in #38) was written specifically so a Windows run would be meaningful: it drives real npm against a synthetic fixture in ~200ms with no network, rather than cloning wordpress-develop.

2. main.js has no seam for the child-process logic

src/main.js calls require('electron') at the top, so node --test cannot import any of it. Anything that lives there is untestable by construction, which is why both src/patch.js (#36) and src/npm-runner.js (#38) were carved out as Electron-free modules.

Two pieces of genuinely tricky logic are still stranded in main.js:

• ensureNodeShimDir() — writes the shim scripts. Windows-specific string generation, zero test coverage, and the mechanism the whole "zero prerequisites" promise rests on.
• runNpmWithEngineRetry() — the spawn/retry loop. Its decision was extracted into a pure function (shouldRetryWithRelaxedEngines) and is tested, but the loop around it isn't. That loop is where two real bugs were caught by hand during Retry npm install with relaxed engine checks when a dependency demands a newer Node #38: retrying a run the user had cancelled, and missing the EBADENGINE marker when it straddled a stream-chunk boundary.

Moving these into npm-runner.js (with spawn injectable) would let the whole fail → detect → retry → succeed cycle be asserted, and would leave main.js as IPC wiring.

Suggested order

1. npm test in CI — small, independent, and immediately makes every later change safer.
2. The main.js extraction — larger and touches production code, so better once CI can catch a regression.