Attach GitHub token only to configured GitHub hosts

[SyedAnas01]

BearerAuthTransport sets the Authorization header on every request it processes. Go's net/http strips the Authorization header when a redirect crosses to a different host, but that only covers headers set on the initial request. Because this transport re-adds the header on every hop, a redirect that leaves the configured GitHub hosts would carry the token to the redirect target.

Today that is not reachable with an attacker-controlled destination, because GitHub's cross-host redirects (release assets, archives) resolve to GitHub-owned hosts such as objects.githubusercontent.com and codeload.github.com. This change stops the transport from relying on that invariant: it attaches the token only when the request host is one of the configured GitHub hosts (REST, GraphQL, upload, raw), so any redirect off them travels without the credential.

A CheckRedirect that strips Authorization does not work here, because the header is re-added by the transport on the next hop. The credential decision has to live in the transport, at the point where the header is set. An empty AllowedHosts preserves the prior behavior, so this is backward compatible; the three production construction sites populate it from the configured hosts.

Tests cover the token being sent to allowed hosts, withheld from a non-allowed redirect target and from arbitrary hosts, and the empty-AllowedHosts default. This is a hardening change, not a response to a known exploit.

[SyedAnas01]

Following up on PR #3056 from back in August (the cross-host token-scoping fix). The PR description framed it as hardening rather than a response to an active exploit, so this might not clear your bar for an advisory — but if your team does see it that way, would you consider opening one? Fine either way, just didn't want it to sit unasked.

Anas