Built-in gh in proxied sessions supports GitHub Enterprise hosts and explains itself better

What

In some sessions, especially cloud sessions that reach GitHub through a proxy (a go-between service that forwards requests), the gh command Claude Code provides is not the real GitHub CLI. It is a small built-in stand-in where only gh api works, already signed in through the session's GitHub proxy. This release reworks that stand-in:

• A --hostname is now checked as a GitHub Enterprise address and the API address is worked out from it. Before, only a fixed list of hosts was allowed. A bad name gets an error saying it is not a GitHub Enterprise host.
• Unsupported commands such as gh pr create are mapped to the equivalent gh api form.
• Requests to a host the proxy does not serve get a hint, and redirects to other hosts are refused with an explanation.
• The refusal message now says that gh api <REST endpoint> works, that no other gh command exists, and gives an example: gh api repos/{owner}/{repo}/pulls/123.
• The help text now describes the stand-in's scope, with a separate version for GitHub Enterprise, and says a real GitHub CLI installed during the session takes over once it is on PATH (the list of folders the shell searches for commands).
• Error wording now says "built-in gh" instead of "gh stand-in".
• New text was added that describes gh to the model as Claude Code's built-in GitHub client, not the GitHub CLI, with versions for Enterprise, any host, no jq, and runner setups. No place in this release was found that uses it yet.

Why

In proxied and cloud sessions, gh becomes usable with GitHub Enterprise and its errors point to what will work, so Claude should waste fewer attempts on gh commands that do not exist there.