Workflow-level `GH_HOST` leaks into Copilot CLI install step

[jaroslawgajewski]

Test result (v0.58.0): Fresh compilation emits the Install GitHub Copilot CLI step with no env: block. The step inherits the workflow-level GH_HOST (e.g., a GHES hostname) causing the install script to auth against the wrong host. 0 occurrences of GH_HOST: github.com found.

Problem: When a workflow sets env: GH_HOST: <ghes-host> (required for GHES), this env var propagates to the Install GitHub Copilot CLI step. The Copilot CLI binary is downloaded from github.com and requires github.com authentication. The leaked GH_HOST causes the install to attempt auth against GHES, failing with 401.

Expected behavior: The Install GitHub Copilot CLI step should be isolated from workflow-level GH_HOST overrides. The compiler should emit env: GH_HOST: github.com on this step automatically.

Suggested fix: The compiler should always emit an explicit env: GH_HOST: github.com override on the Install GitHub Copilot CLI step, regardless of the workflow-level GH_HOST value.