fix: emit GITHUB_HOST in MCP server env for GHES targets via tools.github.host

[Copilot]

Compiled lock files never included GITHUB_HOST in the MCP server container env, causing all GitHub API calls to target api.github.com on GHES deployments (resulting in 401/404). Users had to manually inject the env var after every recompile.

Changes

• New tools.github.host frontmatter field — accepts a bare hostname or full https:// URL; silently ignored when set to github.com or api.github.com
• normalizeGitHubHost() — canonicalizes the value: strips trailing slashes, prepends https:// if scheme is absent, returns "" for default GitHub targets
• Docker renderer (RenderGitHubMCPDockerConfig) — emits "GITHUB_HOST": "<url>" into the container env block when host is non-empty
• TOML renderer (renderGitHubTOML, Codex engine) — same treatment
• GitHubMCPDockerOptions.Host — plumbed through from RenderGitHubMCP → options struct → renderer

Usage

tools:
  github:
    host: ghes.example.com   # bare hostname — https:// added automatically
    # or: host: https://ghes.example.com

Produces in the lock file:

"env": {
  "GITHUB_HOST": "https://ghes.example.com",
  "GITHUB_PERSONAL_ACCESS_TOKEN": "...",
  "GITHUB_TOOLSETS": "..."
}

[pelikhan]

@copilot the compiler should add a step to try to info the GH_HOST at runtime if the host field is not configured.

[Copilot]

@copilot the compiler should add a step to try to info the GH_HOST at runtime if the host field is not configured.

Done in 14c68ed. When tools.github.host is not configured, the compiler now emits a detect-github-host bash step that reads GH_HOST at runtime, normalises it to a full https:// URL, and writes it as a step output. That output flows through a new GITHUB_MCP_HOST env var into the MCP gateway container, where it becomes GITHUB_HOST inside the GitHub MCP server's env — matching the same pattern used for lockdown auto-detection.