ci: rename branch-protection caller job id to branch-protection

[rubenvdlinde]

GitHub names a reusable-workflow status context <caller-job-id> / <called-job-name>.

This repo's caller job id was not branch-protection, so the shared branch-protection
workflow reported under the wrong context name. The org rulesets (Main Branch Protection
id 14128365, Beta Branch Protection id 14128357) require exactly:

branch-protection / check-branch
quality / Quality Report

No name match means the required context never reported at all — not as a failure, as
nothing. The PR sits at BLOCKED forever, and the absence of the check is visually identical to
the check merely not having finished yet. That is the whole defect: a check's absence looks
exactly like its success is still pending.

This renames the caller job id so the context matches. It does not change what is required and
does not touch any ruleset or branch protection — that is a governance decision, not a code
one.

Irony worth recording: this PR itself has to be admin-merged, because the defect it fixes is
precisely what makes the required context unreportable on the current tip.

[github-actions]

Quality Report — ConductionNL/scholiq @ 02c443f

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		❌
stylelint		❌
build		❌
composer			❌	✅ 100/100
npm			❌	❌
PHPUnit					⏭️
Newman					⏭️
Playwright					⏭️

---

Quality workflow — 2026-08-04 06:17 UTC

Download the full PDF report from the workflow artifacts.

[rubenvdlinde]

Dedupe pass, 2026-08-08. Still valid, not superseded — left open deliberately.

Verified by reading the file on each ref rather than by PR title:

$ git show origin/main:.github/workflows/branch-protection.yml   -> jobs.check
$ git show origin/beta:.github/workflows/branch-protection.yml   -> jobs.check
$ git show origin/development:.github/workflows/branch-protection.yml
                                                                 -> jobs.branch-protection

So development already carries the fix; main and beta do not. These two PRs are the only thing that puts it there without waiting on the promotion chain.

One difference worth recording before either lands: development's version dropped secrets: inherit and added permissions: {}. That is safe — the shared branch-protection.yml job check-branch does no checkout, makes no API call and reads only github.base_ref / github.head_ref, so it needs no token. The two spellings therefore behave identically.

Not merged by me: this pass is scoped to development, and my instructions forbid pushing to main or beta. #4 (development -> beta) would carry the same content to beta if it lands first, which would make this PR's beta variant a no-op — worth checking the file again at that point rather than assuming.

[rubenvdlinde]

Closing: this targeted main directly, which is wrong for app repos — changes must flow development → beta → main. Verified that development already carries the renamed branch-protection caller job id, so this PR is redundant rather than lost.