ci(test): skip test-trigger-other-job when token is read-only

[bearomorphism]

Description

The test-trigger-other-job job in .github/workflows/test.yaml runs gh workflow run, which requires actions: write on the GITHUB_TOKEN. This call fails with HTTP 403 (Resource not accessible by integration) in two cases where the token is read-only:

• Fork PRs — fork-originated PRs always get a read-only GITHUB_TOKEN for security.
• Dependabot PRs — even though the branch is in the same repo, the dependabot[bot] actor receives a restricted token by default.

Examples of the resulting failures:

• build(deps): bump actions/github-script from 8 to 9 in the all-actions-dependencies group #15 (dependabot bump) — failing job log
• docs(examples): gracefully handle no bump-eligible commits #17 (fork PR) — failing job log

These permanent failures add noise to PR checks and make it impossible for fork-based or dependabot-driven PRs to get a green CI without maintainer intervention.

Change

Add a guard so the job is skipped when the token will be read-only:

test-trigger-other-job:
  runs-on: ubuntu-latest
  if: >-
    github.event.pull_request.head.repo.full_name == github.repository &&
    github.actor != 'dependabot[bot]'
  steps: ...

The job continues to run on:

• PRs from same-repo branches authored by humans (where the token has the right permissions)
• Direct pushes to main (no pull_request context)

Why not other approaches?

• pull_request_target would give fork PRs a writeable token — major security risk, not appropriate here.
• continue-on-error: true on the trigger step would hide real failures, making the test meaningless.
• A workflow-level permissions: { actions: write } block does not help: fork and dependabot tokens stay read-only regardless.

Checklist

• I have read the contributing guidelines

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: GitHub Copilot