Support HTTPS + token pushes (CI-friendly; prerequisite for scheduled runs)

[silug]

Problem

puppetsync pushes over SSH: git_push_to_remote runs git push <remote> against the fork's ssh_url (set up by ensure_git_remote from user_repo_fork.ssh_url), which requires a working ssh-agent. That's fine interactively, but it's the last blocker for running puppetsync unattended (#56): CI runners and scheduled jobs have a GITHUB_API_TOKEN, not an SSH identity.

This has been a stretch-goal TODO in plans/init.pp for years:

# - [ ] push changes using HTTPS basic auth + GitHub token (CI friendly)

Proposed design

• ensure_git_remote gains a transport choice: when git.push_transport: https (session config; default remains ssh), use the fork's clone_url (https://github.com/<user>/<repo>.git) as the remote URL.

• The push itself authenticates with the existing GITHUB_API_TOKEN without writing the token to disk or the remote URL — e.g.:

  git -c credential.helper='!f() { echo username=x-access-token; echo password=$GITHUB_API_TOKEN; }; f' push ...
  

  (env-var indirection keeps the token out of process listings and .git/config).

• Nothing else changes: fork creation, PR creation, and the approve/merge plans already use the API token.

Notes

• The token needs repo scope (it already does, for fork/PR creation) — in GHA, a fine-grained PAT or GitHub App token for the bot account, since the default GITHUB_TOKEN can't push to a fork owned by another account.
• Verification can follow the established pattern: unit-spec the remote-URL/credential-helper construction, and e2e against a local file:// "fork" remote to prove the push path without touching GitHub.
• With this, Full idempotency: repos that need no changes must pass through cleanly #49 (idempotency), Speed up re-runs: fetch/reset existing clones instead of rm -rf + full re-clone #53 (fast re-clones), and Build inventory dynamically from the GitHub API instead of hand-maintained repolists #55 (dynamic inventory) merged, Scheduled org-wide puppetsync runs (continuous baseline enforcement) #56 (scheduled org-wide runs) has no remaining technical prerequisites.