ci: add plumber workflow security check

[Totara-thib]

Companion to #1040, merge that one first: the check added here flags the unpinned action and the missing permissions blocks until the hardening lands, then it goes green.

This adds Plumber to CI, the tool I used to find those issues in the first place. It scans the workflows on each push to main and on each PR, and fails when something regresses: an unpinned action, a job without a permissions block, an archived dependency, a known CVE, that kind of thing.

• plumber.yml: pinned by sha, minimal permissions, findings go to the security tab as SARIF (skipped on PRs from forks, the report stays as an artifact there).
• .plumber.yaml: a 14 line overlay that inherits the CLI's built-in baseline, you only see what differs for this repo: one control is off with a comment saying why (the release jobs restore the npm cache on release triggers, scoping that cache key is a good follow-up but its own change). Everything else, including new controls in future releases, follows the defaults automatically.
• README.md: one line, the score badge under the license one.

Score badge

I enabled score-push on the action. It works like OpenSSF Scorecard's published results: every run, on any branch, publishes the score to score.getplumber.io, and that feeds the badge in the README. Scores are public and the badge always shows the state of main. A failed publish never fails your CI. Until the first run the badge reads UNKNOWN in gray, then it flips to the grade. If you would rather not have it, drop the README line and the score-push input, the rest works the same.

With the hardening in, this runs green with a score of A. Set soft-fail: true if you prefer report only, without gating PRs.

To be fully transparent: I work on Plumber. If you do not want the tool in your CI, no hard feelings, the hardening PR is the one that matters and it stands on its own.

[usefulthink]

Again, thanks for providing this. I'll definitely check out plumber for use in our development, but as I already wrote in #1040, we're only using actions from a very narrow set of trusted sources and I currently don't see the need to add plumber to that list.

[Totara-thib]

Again, thanks for providing this. I'll definitely check out plumber for use in our development, but as I already wrote in #1040, we're only using actions from a very narrow set of trusted sources and I currently don't see the need to add plumber to that list.

To clarify what plumber actually checks beyond the pinning from #1040: it reads the workflows and catches the drift dependabot can't see. A new unpinned action slipping into a future workflow, a job holding more token permissions than it uses, injection-prone expressions in run scripts, a pinned version sitting in a known advisory range (the changed-files case), or an action whose upstream repo got archived or deleted. The CLI is open source, the action here is pinned by SHA like everything else, and it runs read only, no token or secret needed.

But your call entirely. If the trusted list stays closed I close this PR, #1040 is the part that matters.