runGH() clobbers GH_HOST env var when a per-checkout token is supplied

[bjartenilsen]

Summary

setup/js/build_checkout_manifest.cjs's runGH() helper clobbers process.env (specifically GH_HOST) due to incorrect object-spread ordering when a per-checkout token is supplied for a repo on a different host (e.g. a GitHub Enterprise Cloud tenant with data residency (a .ghe.com host)).

Impact

When a compiled agentic workflow runs on a .ghe.com (data residency) tenant and a checkout/safe-output handler needs to call gh with a specific per-repo token, the spread order causes GH_HOST (and potentially other env vars) to be overwritten/dropped, breaking gh CLI calls that must target the correct .ghe.com host rather than github.com. This causes the gh invocation to silently target the wrong host, resulting in confusing "not found" / auth failures deep in the safe-outputs pipeline (e.g. during create_pull_request).

Root cause

In runGH(), the environment object passed to the child process spreads process.env after the per-call GH_HOST/token overrides, so the real process.env.GH_HOST (or lack thereof) wins over the intended override — effectively discarding the host-specific configuration for that call.

Fix

We patched this internally by reordering the spread so call-specific env overrides are applied after (and thus win over) the base process.env spread. Fixed in our internal fork at commit f1416a875b6cf59c44b7e0d71be4ba344f2f5e87 (tag v0.88.7-ghhostfix). Happy to open a PR with the fix if useful — this affects any gh-aw deployment on a .ghe.com (data residency) tenant where safe-output handlers need to authenticate against a non-github.com host (a .ghe.com data-residency tenant).

Environment

Discovered running gh-aw compiled workflows against a GitHub Enterprise Cloud tenant with data residency (a .ghe.com host), targeting cross-repo create_pull_request safe outputs.