Duplicate 'Authorization' header (HTTP 400) on git ops in push_to_pull_request_branch safe output

[dsyme]

Summary

push_to_pull_request_branch safe outputs fail intermittently with:

remote: Duplicate header: 'Authorization'
fatal: unable to access 'https://github.com/.../': The requested URL returned error: 400

This happens on git ls-remote / git fetch / git push from the safe_outputs job.

Root cause

http.<url>.extraheader is a multi-valued git config key. In the safe_outputs job there were two credential sources both setting it:

1. The checkout step uses persist-credentials: true, which writes an http.<url>.extraheader = Authorization: Basic ... entry into .git/config.
2. The handler actions/setup/js/push_to_pull_request_branch.cjs additionally injected a second extraheader via GIT_CONFIG_COUNT / GIT_CONFIG_KEY_0 / GIT_CONFIG_VALUE_0 env vars (getGitAuthEnv).

Because the key is multi-valued, git sends both values, producing two Authorization headers on the wire → the server rejects the request with Duplicate header: 'Authorization' / HTTP 400.

create_pull_request.cjs already relies solely on the persisted .git/config credentials and does not inject getGitAuthEnv — push_to_pull_request_branch.cjs was the lone outlier.

A secondary issue: the persisted checkout credential used the default GITHUB_TOKEN rather than the resolved PR push token, so custom-PAT / cross-repo push configurations could persist the wrong credential.

Fix

1. Stop the handler from injecting a second credential — rely on the credentials persisted in .git/config by the checkout (consistent with create_pull_request.cjs).
2. Persist the resolved PR push token (resolvePRCheckoutToken) into the safe_outputs checkout so the single retained credential is the correct one (also fixes custom-PAT / cross-repo cases).

getGitAuthEnv remains in git_helpers.cjs for the other handlers that still need it (gh operations / cleaned-credential contexts).