fix(cli): engage the gh stubs on Windows instead of calling the real API

[ophiocus]

Closes #241. The suite's gh stubs never engaged on Windows — the fixture PATH was joined with a hard-coded : and the stub is an extensionless script — so eight tests resolved the developer's real gh and called api.github.com, including the one named "deterministic GitHub fixtures". This PR makes the stubs engage on every platform, adds a belt so a future fallthrough can never reach the real API, and stands up the verify-windows CI job so the whole Windows-only defect class fails in CI instead of on contributors' machines.

Why a seam, not a shim

The obvious fix — a gh.cmd wrapper beside the stub — cannot work: Node refuses to execute .cmd/.bat through execFile without a shell by design since CVE-2024-27980 (the same refusal behind #182's spawn EINVAL). No PATH arrangement makes a script stub executable there. So the templates gain a minimal, shell-free seam:

const GH_BIN = process.env.FACILITY_GH_BIN ?? "gh";
const GH_ARGS = process.env.FACILITY_GH_ARGS ? JSON.parse(process.env.FACILITY_GH_ARGS) : [];

Production behavior is byte-identical (default "gh", no args, no shell ever). Tests set FACILITY_GH_BIN=process.execPath and pass the stub script via FACILITY_GH_ARGS — works identically on POSIX and Windows.

The changes

What	Where
Seam in the two gh-calling templates	templates/delivery/verify.mjs, templates/doctor/resolve.mjs
Tests drive the seam; PATH joined with path.delimiter	test/delivery.test.mjs, test/doctor-policy.test.mjs
Fail-offline belt: stub env pins GH_HOST=gh-stub.invalid + dummy token, so if a stub ever falls through again the suite dies against an unresolvable host, never against the real API	both test files
POSIX 0600 asserts scoped to platforms with mode bits (NTFS has none); the secret-not-logged assert still runs everywhere	test/platform.test.mjs
init e2e skipped on win32 with #230 as the recorded unskip criterion (its symlink bug, not this PR's subject)	test/init.test.mjs
verify-windows job: CLI suite + guards on windows-latest, same pinned action SHAs as verify	.github/workflows/ci.yml

Why the CI job belongs here

Ten currently-open issues are Windows-only defects invisible to ubuntu-latest (#182 #183 #167 #191 #217 #227 #228 #230 #240 #241 — inventory in #241). Every one shipped because nothing red ran on Windows. The job covers the pure-Node surfaces (CLI suite, guards) in ~3 minutes — no Docker, no Postgres — and this very PR is its first proof: before it, that job fails 11 tests; with it, green.

Verified

• Windows 11, Node 22.23.2, pnpm 11.20.0 (the environment test(cli): suite is POSIX-only — gh stubs never engage on Windows, so eight tests call the real GitHub API #241 was found on): 86 pass / 11 fail before → 96 pass / 0 fail / 2 skip after.
• Linux (WSL, same versions): 97 pass / 0 fail / 1 skip — no regression; the seam's default path is exercised by the entire existing suite.
• Biome clean through the init e2e's own formatter gate over the installed templates.

Found while running the suite on a real Windows machine — happy to iterate on any of it, and the Windows arc continues in #240/#227.

[adrian-lorenzo]

Thanks for the contribution!

FACILITY_GH_BIN and FACILITY_GH_ARGS are now trusted from the ambient environment by the shipped delivery verifier. The builder and repository checks run before the delivery steps, and either can persist these variables through $GITHUB_ENV. The verifier would then execute the selected binary with GH_TOKEN, allowing earlier code to replace gh and fake the GitHub evidence or run inside the privileged finalization step.

Please keep the test seam at the module boundary—for example, by injecting the GitHub runner into an exported entry point—while the production entry point always invokes the fixed executable. Add a regression test showing that hostile ambient variables cannot redirect it.

The Windows CI coverage and offline safeguard are worth keeping. Once this boundary is sealed, this will be a strong improvement.

[ophiocus]

Sealed in 48e510a — and thank you for spelling out the attack path; $GITHUB_ENV persistence from an earlier step is exactly the kind of thing I should have modeled before reaching for env vars at all.

The seam now lives where you pointed:

• verify.mjs exports runDelivery(mode, { gh }) and resolve.mjs exports main({ gh }) — the injectable runner exists only as a parameter on those entry points. The script paths construct the fixed "gh" executable inline; nothing about the invocation is readable from the environment anymore.
• The delivery tests and the resolver integration tests now inject the runner in-process through the exported entry points (the doctor tests got simpler for it — the fixture map became a closure instead of a stub binary).
• Two spawn-path regression tests prove the boundary holds: each launches the real script with a hostile FACILITY_GH_BIN pointing at a marker-writing binary plus GH_HOST=gh-stub.invalid — the marker is never written, and the fixed gh dies offline instead of reaching the API. If anyone ever reintroduces an ambient override, those two go red.

Verified: Linux 99 pass / 0 fail, Windows 98 pass / 0 fail on the same head; the verify-windows job you liked stays in and re-proves it on the hosted runner.

[ophiocus]

Status note: verify-windows and minimum-node are green on the merged head; the verify red is not this PR — two browserslist advisories published ~18:00Z today fail the audit step of every run repo-wide. #267 carries the one-line floor (house override pattern) that clears it for all open PRs.