EXP-23278: Keep a GitHub URL rewrite the job already configured

[a-olkhovskyi]

When the job that runs s7 has already set up github.com URL rewriting — buildserver-utils' set-https-auth.sh exports GIT_CONFIG_* before invoking anything, and a git config file counts too — s7 keeps it instead of stacking its own rule on top.

Stacking fights the job's setup: its rewrite target carries credentials of its own (https://user:token@github.com/), and s7's github.com-scoped extraheader applies to that URL as well (git ignores the userinfo part when matching config), so the request ends up with two different credentials on it.

The check mirrors github_rewrite_configured() in get-or-update-blobless-git-repo.sh: ask git for the effective config, url.<base>.insteadOf mentioning github.com on either side, case-insensitive; other hosts and pushInsteadOf don't count. It runs once per process and only on the token path — SSH users are unaffected.

A nested s7 stays distinct: the rewrite it inherits is an ancestor s7's, marked with S7_GIT_AUTH_INJECTED, and #93's verbatim reuse still applies.

Testing. Full suite green (282 tests). New unit tests for the decision plus one that runs real git to confirm GIT_CONFIG_* rules come back in the expected shape. Smoke-tested with the built binary: token only → injects; token + rewrite via GIT_CONFIG_* → keeps; token + rewrite in a config file → keeps; rewrite for another host → injects; no credentials → SSH.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes subrepo clone/fetch/push auth selection in CI when tokens and pre-existing git URL rewrites coexist; logic is well-tested but mis-detection could leave repos on SSH or wrong credentials.

Overview
When S7_GIT_USER / S7_GIT_TOKEN (or GH_* fallbacks) are set, s7 no longer always injects its own GIT_CONFIG_* GitHub rewrite and http.https://github.com/.extraheader. It first checks effective git config (one git config --get-regexp per process, via a dedicated path that avoids re-entering auth env setup) for an existing url.<base>.insteadOf rule that mentions github.com on either side (case-insensitive); pushInsteadOf and other hosts do not count.

If such a rewrite is already present and the environment was not stamped by an ancestor s7 (S7_GIT_AUTH_INJECTED), s7 leaves git config alone and logs that it is keeping the job’s setup. That avoids fighting CI setups like set-https-auth.sh, where credentials live in the rewrite URL and s7’s scoped extraheader would add a second Authorization path.

Nested s7 behavior is unchanged: environments with the marker still reuse verbatim; foreign rewrites without the marker still get s7’s builder appended (new test clarifies marker vs foreign GIT_CONFIG_*).

Help text documents the new behavior. Unit tests cover the parser, edge cases, marker semantics, and a real-git check that GIT_CONFIG_* rules surface in the expected shape.

^{Reviewed by Cursor Bugbot for commit ee0fbaa. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pastey]

I would suggest to remove the whole feature in favour of buildserver-utils

[a-olkhovskyi]

Superseded by #95 — we're removing the HTTPS token auth feature from s7 entirely, so there's no rewrite logic left to tweak.