fix(ci): toolchain rebuild bot evaluates development, not the default branch

[Wikid82]

Problem

The daily schedule (and the weekly rebuild's workflow_call) runs of toolchain-image.yml checked out the default branch (main), computed the toolchain key from main's recipe, and compared it to main's Dockerfile pin:

cur_tag="$(grep '^ARG CHARON_TOOLCHAIN_TAG=' Dockerfile ...)"   # main's Dockerfile
if [[ "$cur_tag" == "$KEY" ... ]]; then moved=false            # always matches on main -> no PR

On main the pin is self-consistent, so open-bump-pr's "did the pin move?" check was never true and no bot PR was ever opened — even though open-bump-pr targets base: development, and development accumulates its own Dockerfile ARG bumps (x/net, x/crypto, …) that move the toolchain key independently of main.

Net effect: development-side toolchain-pin drift had no automated detection or repair path. It only surfaced when a main → development propagation PR ran verify-toolchain-pin against the merge recipe (#1320 / #1322) — by which point the pin was already stale on the branch and no bot PR existed to fix it. Today's 06:16 UTC scheduled run executed fine and still opened nothing, for exactly this reason.

Fix

Pin the build-toolchain, trivy-scan, and open-bump-pr checkouts to development on every non-pull_request trigger:

ref: ${{ github.event_name != 'pull_request' && 'development' || '' }}

• schedule / workflow_dispatch / the weekly workflow_call (whose github.event_name is the caller's schedule) → evaluate + bump development, matching where open-bump-pr already sends its PR.
• pull_request → ref: '' → default merge-ref checkout, unchanged.
• sync-pin-on-pr is untouched — it's PR-only, already checks out the PR head, and stays guarded off for main/development/nightly/feature/beta-release head refs (the 2026-09-08 incident guard).

Ternary uses != 'pull_request' && 'development' || '' (not == ... && '' || ...) because an empty string is falsy in GitHub Actions expressions and would collapse the ternary.

Verification

• actionlint + check-yaml + semgrep clean (pre-commit).
• Behaviour is exercised by the next scheduled run / by chore: propagate changes from main into development #1322's own sync-pin-on-pr (its head is a normal topic branch, so it self-heals the merge-recipe pin regardless of this change).

Follow-up to the #1320 / #1322 toolchain-freshness investigation.

https://claude.ai/code/session_01Jz4LgwfkxaF8E7TdAgk94y

[github-actions]

✅ Supply Chain Verification Results

✅ PASSED

📦 SBOM Summary

• Components: 1769

🔍 Vulnerability Scan

Severity	Count
🔴 Critical	0
🟠 High	0
🟡 Medium	0
🟢 Low	0
Total	0

📎 Artifacts

• SBOM (CycloneDX JSON) and Grype results available in workflow artifacts

---

_{Generated by Supply Chain Verification workflow • View Details}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.