docs(examples): gracefully handle no bump-eligible commits

[bearomorphism]

Description

This PR contains two related changes that together fix two distinct CI papercuts uncovered by commitizen-tools/commitizen#1950 (suggested in this comment).

---

1. docs(examples): gracefully handle no bump-eligible commits

When users copy-paste these example workflows and only push commits that do not trigger a version bump (e.g. docs:, ci:, build(deps):), cz bump --yes exits with code 21 (NO_COMMITS_TO_BUMP), which causes the entire workflow to fail.

This commit updates both examples/bump-release.yaml and examples/trigger-other-job/.github/workflows/bump-release.yaml so that:

• The bump step passes --no-raise 21 to cz bump to avoid hard-failing on the no-commits case.
• It compares HEAD before and after the bump; if unchanged, it logs a message, sets bumped=false and exits 0.
• The subsequent Build changelog, Release and trigger other workflow steps are guarded by steps.bump-version.outputs.bumped == 'true' so they are skipped on no-op runs.

This mirrors the same pattern that commitizen itself adopted in its own bumpversion workflow.

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

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
• An earlier run of this very PR — failing job log

This commit guards the job with:

if: >-
  github.event.pull_request.head.repo.full_name == github.repository &&
  github.actor != 'dependabot[bot]'

The job continues to run on PRs from same-repo branches authored by humans, where the token has the right permissions.

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

Expected Behavior

• Users who copy-paste the example workflows now get one that succeeds gracefully when only non-bump-eligible commits are pushed.
• Fork PRs and dependabot PRs no longer have a permanently failing test-trigger-other-job check; same-repo human PRs and pushes to main retain full coverage.

[bearomorphism]

draft this and will do a human review later