the emitted gh api scripts carry GH_TOKEN only: PrPlanReport posts unauthenticated on Forgejo, the same defect #2333 fixed at runtime

[lex00]

What

#2333 (PR #2350) fixed the credential half of reaching a non-github.com host
for the two calls chant makes at runtime —
postOrUpdateComment and postOrUpdateGithubIssue, both now going through
ghCredentialEnv, which sets GH_ENTERPRISE_TOKEN beside GH_TOKEN.

Chant also emits gh api into generated YAML, and those scripts never
pass through that activity. Each already builds a correct full URL from
GITHUB_API_URL (the #2305 URL half) and then sets GH_TOKEN alone, which
is the exact shape #2333 measured sending no Authorization header at all
against a live Forgejo 12.0.4+gitea-1.22.0 instance.

The call sites

lexicons/github/src/composites/pr-plan-report.ts:154 — the sharpest
one. env: { GH_TOKEN: "${{ secrets.GITHUB_TOKEN }}" }, feeding a
stickyCommentScript whose GET/PATCH/POST are built from
api_base="${GITHUB_API_URL%/}". The forgejo lexicon re-exports every github
composite through its dialect, so this composite runs on Forgejo today with a
URL that reaches /api/v1 and a credential gh will not attach to it.
Nothing refuses it the way the Op generator refuses findingMode: "issue".
#2304 already flagged this file for the URL half; this is the credential
half of the same file.

lexicons/github/src/components/generate-op-pipeline.ts:396 — the
gated-apply notice job's four gh api calls, GH_TOKEN + GH_REPO only.
Not emitted for forgejo today (#2294 drops the job), so this is GHES-only
exposure — but GHES is in the same gh token class as Forgejo, per #2333's
matrix.

examples/github-pr-preview/src/ci/preview.ts:93 — same shape. Matters
because it is the template users copy, and its docs mirror at
docs/src/content/docs/tutorials/github-pr-preview.mdx:172-177 copies it
verbatim.

Not this

generate-op-pipeline.ts:689-690 sets only GITHUB_TOKEN and GH_TOKEN on
the Op step and is inherited verbatim by the forgejo generator. That is
correct as it stands: it is the input commentTokenFrom reads, and #2333
fixed the layer that re-forwards it. Named here so it does not get "fixed"
twice.

A separate, third family

gh calls that take neither a URL nor a host, and so default to github.com
even on GHES: generate-op-pipeline.ts:357 (gh issue create with only
GH_REPO set, sitting inside a script whose other four calls are
full-URL), the ambient gh pr/gh label calls in
packages/core/src/op/activities/lexicon-upgrade.ts (342, 356, 372, 388,
391, 708, 712), and packages/core/src/lifecycle/rollback.ts:110.
reconcile.ts's own gh issue create and gh pr create fallbacks are in
this family too, but the issue one is deliberate and documented — it is the
outside-CI branch where gh auth login is the credential.

Worth its own issue rather than folding in here; the fix shape is different
(supply a host or a URL, not a variable).

Do

Decide whether the emitted scripts should set GH_ENTERPRISE_TOKEN beside
GH_TOKEN the way ghCredentialEnv does, and verify against a real Forgejo
instance from a shell with no stored gh auth login — the condition #2304's
verification did not reproduce and the reason #2333 shipped in two releases.

Refs #2291, #2304, #2305, #2315, #2332, #2333, #2350.