chore(ci): toolchain key should ignore comment-only .trivyignore edits

[Wikid82]

Problem

The toolchain freshness guard (Toolchain pin freshness (verify-toolchain-pin)) fails when .trivyignore changes in a comment-only way. scripts/toolchain-key.sh hashes .trivyignore byte for byte (input #5), so editing a comment line moves the toolchain key even though the effective ignore set is unchanged. The Dockerfile pin (CHARON_TOOLCHAIN_TAG) then looks stale, and the required check fails.

Evidence

• Release PR chore(main): release 0.44.3 #1504 (release-please--branches--main): the check failed with Toolchain recipe/pins changed (recomputed caddy-crowdsec-ee1028e3a9426fa5, Dockerfile pins caddy-crowdsec-04ecbc386f253556).
• Commit bdaf4f44 on that branch changed one comment line in .trivyignore (zlib -r0 to -r1 in a comment; the suppressed CVE ID line is untouched) alongside the functional .grype.yaml version bump.
• Reproduced locally: scripts/toolchain-key.sh on main returns 04ecbc38… (matches the pin); on the release branch it returns ee1028e3….
• Failing job: https://github.com/Wikid82/Charon/actions/runs/37572083310/job/112632740683

Why it is not self-healing

toolchain-image.yml rebuilds on .trivyignore changes and opens bump PRs for development, main and nightly. A commit pushed directly to the release-please branch is none of those, so nothing moves the pin there. The guard also cannot tell a comment edit from a real suppression change, so documentation edits force a full toolchain image rebuild.

Severity

Medium (CI friction): blocks required checks on release and PR branches, and forces needless image rebuilds. No security impact.

Suggested approach

1. In scripts/toolchain-key.sh, hash only the effective .trivyignore entries (strip comment and blank lines, and trailing whitespace) instead of the raw file.
2. Bump SCHEMA_VERSION (the extraction logic changes), accepting a one-time rebuild of the toolchain image and a pin refresh.
3. Update scripts/tests/toolchain-key.bats: keep "changes when .trivyignore changes" (add an entry), and add "does not change when only a comment or blank line changes".
4. Check whether other inputs have the same comment sensitivity (the extracted Dockerfile stage text is intentionally raw; confirm that is still desired).
5. Land via development as a normal PR, since it changes CI tooling and rebuilds the image.

Immediate unblock for #1504 (separate from this fix)

Either let the pending toolchain image job finish and see whether a bump follows, or revert the comment-only .trivyignore change on the release branch (the functional fix is in .grype.yaml). Note release-please may rewrite its branch on its next run.

[Wikid82]

Update from release PR #1504 (run 37572083277 / 37572083310 / 37572083296):

• Build & publish toolchain image passed and published :caddy-crowdsec-ee1028e3a9426fa5, but nothing moved the Dockerfile pin, so the pin guard kept failing.
• Sync toolchain pin onto the PR branch was skipped. It only runs when the PR author and actor are not github-actions[bot], and the head ref is not main/development/nightly/feature/beta-release (see the if: in .github/workflows/toolchain-image.yml). A release-please PR does not satisfy these.
• Open toolchain digest-bump PR was skipped. It only runs on schedule, workflow_dispatch, workflow_call and push, never on pull_request.
• Result: two jobs failed on the stale pin: Toolchain pin freshness (verify-toolchain-pin) ("recomputed ee1028e3…, Dockerfile pins 04ecbc38…") and merge-and-publish ("Pinned toolchain image label != recomputed recipe key").

So for a release-please branch (and any other PR whose head is excluded from the sync job), a key-moving edit cannot self-heal. The comment-insensitive key proposed above removes the most likely trigger (comment-only .trivyignore edits). A real key-moving change on a release-please branch would still need a manual workflow_dispatch and a pin bump. Worth deciding whether that case should be handled or documented.