Rebase pushes with the machine-user PAT (action-translation#125)

[mmcky]

Completes the production half of action-translation#125: the rebase workflow now pushes with the machine-user PAT instead of the default GITHUB_TOKEN.

Why

Commits pushed with GITHUB_TOKEN do not trigger workflows — GitHub's recursion guard — so a rebased branch ends up with a run-less head: force-pushed re-translated content lands unreviewed, and with required status checks a run-less head blocks merging. Measured both ways on the test harness, same repo, same day: 13 GITHUB_TOKEN-rebased heads with zero workflow runs, versus a PAT-refreshed head whose review workflow triggered normally.

This is the same reasoning sync mode has always applied — its PRs trigger the review workflow because it passes the PAT. Rebase pushing to the same PRs with a weaker token was an inconsistency, not a decision.

Safety

• No loop risk: rebase triggers on closed; the runs a PAT push triggers (CI, review) never push back.
• Fork exposure: none, including on public repos — secrets are withheld from pull_request workflows triggered from forks regardless of repo visibility, and the job's if only matches branch prefixes the tooling creates.
• The org-secret grant for this repo is in place (a missing grant fails loudly: Input required and not supplied: github-token).

The harness (test-translation-sync.zh-cn) has carried this exact configuration in steady state since validation.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the translation rebase GitHub Actions workflow so that rebased branches are pushed using a machine-user PAT, ensuring the resulting force-push triggers downstream workflows (avoiding “run-less head” situations that can block merges when status checks are required).

Changes:

• Update workflow documentation to reflect the CLI command translate forward --github (instead of forward --github).
• Switch the github-token input from the default GITHUB_TOKEN to secrets.QUANTECON_SERVICES_PAT, with inline rationale/comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mmcky]

Deliberately keeping the date — pushing back on this one. The date is provenance, not staleness: it tells a future maintainer when the evidence was gathered and pairs with the linked issue where the runs live. This program's convention is dated empirical claims for exactly one reason: the last undated, "qualitative" rationale in this workflow family — .fa's old cancel-in-progress: false comment — was reasoned-sounding, timeless-sounding, and wrong, and it survived precisely because nothing marked when (or whether) it had ever been tested. Production disproved it across ~15 events. A dated claim invites re-verification when it ages; an undated one reads as eternal truth. If the claim is ever invalidated, the fix is to update the comment with the new evidence and its date, not to remove the timestamp that made the original auditable.

[mmcky]

Pushing back — the property this asks for already exists, and it was field-tested this week rather than assumed. github-token is a required input in action.yml, so an empty resolution fails immediately with the input named: Input required and not supplied: github-token. We observed exactly that live when the org-secret grant was missing on a harness target (first validation attempt of action-translation#124) — the failure was instant and self-explanatory, and the rerun after the grant succeeded from the same event. A per-repo preflight step would restate action.yml's own check while adding template-divergent boilerplate to five copies. Also note the most plausible route to a withheld secret — a fork-origin run — is now skipped entirely by the same-repo head guard added from the other review comment (#130 and estate follow-ups).