fix(release): support optional PAT for release-please PR creation

[OgeonX-Ai]

Root cause

All 13 repos' "Release Please" workflow runs fail on the same fatal error, not the
"commit could not be parsed" lines (those are pre-existing, non-fatal warnings for
merge commits / free-text subjects — release-please skips them from the changelog by
design and continues normally).

The actual fatal error, confirmed by full --log-failed reads on autogen, .github,
and cas-platform:

##[error]release-please failed: GitHub Actions is not permitted to create or approve
pull requests. - https://docs.github.com/rest/pulls/pulls#create-a-pull-request

This is not a workflow YAML permissions problem — the reusable workflow's job
already grants contents: write, pull-requests: write, issues: write, and the
run logs confirm the token was actually issued those scopes
(GITHUB_TOKEN Permissions: Contents: write / PullRequests: write / ...).

It is a repository-level Settings toggle: Settings → Actions → General →
Workflow permissions → "Allow GitHub Actions to create and approve pull requests".
Confirmed via the API on all three sampled repos:

GET /repos/Coding-Autopilot-System/{autogen,.github,cas-platform}/actions/permissions/workflow
{"default_workflow_permissions":"read","can_approve_pull_request_reviews":false}

can_approve_pull_request_reviews: false blocks GITHUB_TOKEN-authenticated PR
creation regardless of the workflow's own permissions: block.

Why gh release list is empty

release-please-action runs both "create GitHub Release for the last merged release
PR" and "propose/update the next release PR" inside a single Manifest.run() call.
When the PR-creation call throws, the whole run aborts — so even after
chore(main): release 1.0.0 PRs were merged, the tag and GitHub Release were never
created. Verified directly: gh api repos/.../autogen/tags → [],
gh api repos/.../autogen/releases → [].

Non-fatal parse warnings

commit could not be parsed: ... Merge pull request #N from ... /
Add MIT LICENSE / Remove test file etc. are expected — these commit subjects are
not Conventional Commits. release-please logs a warning and excludes them from the
changelog; it does not fail the run. No bootstrap-sha / commit-filtering config
change is needed — this is by-design behavior, confirmed by the run continuing past
every one of these warnings to the actual (unrelated) fatal PR-creation error.

Fix in this PR

Adds an optional release-please-token secret input to the reusable workflow,
passed to googleapis/release-please-action as token:, falling back to
github.token when unset:

on:
  workflow_call:
    secrets:
      release-please-token:
        required: false
...
    with:
      token: ${{ secrets.release-please-token || github.token }}

A PAT / GitHub App installation token is not subject to the "Actions can
create/approve PRs" restriction, so this lets any caller opt in with a narrowly
scoped token instead of flipping the broader, org-wide/repo-wide setting (which
affects every workflow in the repo, not just release-please).

Backward compatible — no behavior change for existing pinned callers until they
both (a) repin to a commit that includes this fix, and (b) supply a token via
secrets: release-please-token: ... or secrets: inherit.

What this PR does NOT do (by design, per operator scope)

• Does not flip the repo/org "Allow GitHub Actions to create and approve pull
  requests" setting — that is an administrative action outside this session's
  authorization (denied by the local permission classifier when attempted as a
  read-only capability check).
• Does not create the release-please-token secret — that requires the operator
  to mint a PAT / GitHub App installation token with contents:write +
  pull-requests:write and store it as a repo or org Actions secret.
• Does not re-pin the 13 caller repos to this commit. Callers currently pin the
  reusable workflow by SHA (e.g. autogen's caller pins
  64c1673088ff7802f1270a44f03bc4d7a10631f2), so this fix has no effect until each
  caller is repinned. Re-pinning is deferred pending the operator's choice between
  the two remediation paths below, to avoid 13 speculative PRs before a token/setting
  decision is made.

Remediation paths for the operator (pick one)

1. Zero-code: enable Settings → Actions → General → "Allow GitHub Actions to
   create and approve pull requests" on each of the 13 repos (or once at the org
   level, if not overridden per-repo). Simplest, but broadens what every workflow in
   the repo can do, not just release-please.
2. Scoped token (this PR enables it): create a PAT / GitHub App installation
   token scoped to contents:write + pull-requests:write, store it as
   RELEASE_PLEASE_TOKEN (repo or org secret), then once this PR merges: repin each
   caller to the merge commit SHA and add
   secrets: { release-please-token: \${{ secrets.RELEASE_PLEASE_TOKEN }} } (or
   secrets: inherit if the secret is org-level and visible to the repo).

Verification

• python -c "import yaml; yaml.safe_load(open('.github/workflows/release-please-reusable.yml'))" → YAML OK
• No caller repos were modified in this PR (see scope note above).

Not merging this myself — leaving for review per session authorization.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[OgeonX-Ai]

Packet 1 is now complete on this PR branch. In addition to the reusable workflow token input, the branch now also wires the .github self-caller to pass RELEASE_PLEASE_TOKEN explicitly, which is required for the token fix to apply to the org-dotgithub repo itself.\n\nCurrent verified state:\n- The July 13 live release-please failures in dependent repos are still the PR-creation restriction: GitHub Actions is not permitted to create or approve pull requests.\n- All 12 dependent caller workflows have been prepared locally to consume this reusable workflow change, but they should be repointed to the final merged .github commit SHA after this PR lands, not to the temporary branch-tip SHA.\n- Repo-level secret checks on several canary repos are empty, so canary execution still depends on RELEASE_PLEASE_TOKEN existing at org or repo scope.\n\nPolicy note: this PR is currently blocked by required review on .github/main, not by a CodeQL defect in the Packet 1 diff itself. The failing review-bot/automerge-eligibility checks reflect the existing app/eligibility setup on workflow-touching PRs.