CI: Version suggestion job fails on fork PRs (403 posting comment)

[aesslinger]

Problem

The Version suggestion CI job fails on fork PRs (e.g. #114) with:

message: 'Resource not accessible by integration'
documentation_url: '.../rest/issues/comments#create-an-issue-comment'
status: 403

The job's Compute suggestion, manage comment step (.github/workflows/ci.yml) uses actions/github-script with ${{ secrets.GITHUB_TOKEN }} to post/update an issue comment with the version-bump suggestion. The workflow declares permissions: pull-requests: write on the job, but for a pull_request event triggered from a fork, GitHub Actions issues GITHUB_TOKEN with read-only permissions regardless of what the workflow requests — this is a hard platform restriction for fork-triggered pull_request runs, not something the workflow's own permissions: block can override.

Same root cause shows up as a warning in the Security audit job on fork PRs too: "GitHub Actions are not allowed to use Check API, when executed for a forked repos."

Impact

• Every substantive check (Test, Live PostgreSQL integration, Security audit, PR title, Markdown lint, .tabularium manifest validation) passes fine on fork PRs.
• Only Version suggestion goes red, purely because it can't write the comment — not because of anything wrong with the PR's code, title, or labels.
• This makes every external-contributor PR show a failing CI check that a maintainer has to manually explain/ignore, which is a bad first-contribution experience (see feat: keep a session's transaction alive across batches #114 for a live example, where prerelease:rc was applied correctly but the job's comment-posting step still 403s).

Suggested fix

Standard options for this GitHub Actions limitation:

1. Switch just the Version suggestion job to pull_request_target instead of pull_request (it doesn't need to build/run untrusted code — it only reads github.event.pull_request.title/body/labels — so the usual "don't run untrusted code with elevated permissions" concern is minimal here). pull_request_target runs with the base repo's token permissions even for fork PRs.
2. Alternatively, keep pull_request but gate the comment-posting step so it only runs for same-repo PRs (github.event.pull_request.head.repo.full_name == github.repository), and skip/no-op the comment for forks — classification/labels still work, just no automated comment.
3. Or use a maintainer-scoped PAT stored as a secret specifically for this job (more setup, more to maintain — probably overkill for this).

Option 1 seems like the least-friction fix, but worth confirming the classification step's inputs (github.event.pull_request.*) are still trustworthy enough under pull_request_target for this use case (they are here — no checkout of untrusted code, no execution of PR content).

Repro

Any PR opened from a fork with the workflow's default token permissions reproduces this. #114 is a live example.