fix(auth): GITHUB_TOKEN is sent to any remote that is not recognised as GitLab #1134

git::auth::token_for_url ends with github_token.map(...): whenever the remote is not resolved as GitLab, GITHUB_TOKEN is handed to git for that remote. That covers a remote that is GitHub, but also any host whose forge could not be identified, and self-hosted Gitea, Forgejo and Bitbucket.

So a job that has GITHUB_TOKEN in its environment (every GitHub Actions job does, and people often export a PAT under that name) sends it as the push password to whatever host the remote points at. For a self-hosted Gitea that is wrong but mostly harmless. For a remote on an unknown or third-party host, it discloses a GitHub credential to that host.

FERRFLOW_TOKEN behaves the same way by design: it is the generic token and goes to whatever forge the remote is.

Raised in review on #1132, where it was noted that host-only forge detection does not change this: an unidentified host still gets the GitHub token.

Possible direction

Send GITHUB_TOKEN only when the resolved forge is GitHub (github.com, or GitHub Enterprise confirmed by workspace.forge or the probe). Give the other forges their own variables on the push side, as the API side already does (GITEA_TOKEN / FORGEJO_TOKEN, BITBUCKET_TOKEN), which is also the Gitea gap noted in #1124. An unidentified host then gets no forge-specific token, only FERRFLOW_TOKEN if the user set it.

It is a behaviour change. A self-hosted Gitea pushing today with GITHUB_TOKEN would need GITEA_TOKEN or FERRFLOW_TOKEN, so it wants a note in the release, and possibly a transition period with a warning.