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 branch's caller job id was not branch-protection, so the shared branch-protection
workflow reported under the wrong context name, and the org ruleset requirement
branch-protection / check-branch never reported at all — not as a failure, as nothing.

Several of these beta branches carry a second, independent fault: the reusable workflow was
referenced as Conduction/.github instead of ConductionNL/.github. The Conduction org does not
exist (GET /repos/Conduction/.github -> 404), so on those branches the workflow could not even
resolve. Where present, that is fixed here too — renaming the job id alone would not have made the
context appear.

This matters for beta -> main promotion PRs, whose head is beta, so beta's tip is what
decides the context name and the workflow reference.

Does not change what is required and does not touch any ruleset or branch protection.

[rubenvdlinde]

Reviewed as part of an end-to-end sweep of this repo's open PRs. Correct, and deliberately left for a human — this targets beta, which is the human-gated branch in this fleet. The main twin, #146, met the bar and is merged.

Two separate defects are fixed here, and the second is not in the title:

1. Job id protect → branch-protection. GitHub names a reusable-workflow context <caller-job-id> / <called-job-name>, so the required check publishes as protect / check-branch while the org ruleset requires branch-protection / check-branch. The required check therefore never reports and PRs sit permanently pending — the third shape of a dead gate, alongside falsely-green and falsely-red.

2. Conduction/.github → ConductionNL/.github. beta is still pointing the reusable workflow at the old org. This is a bigger deal than the rename: it means beta's branch-protection call is resolving against a repository that is not where the workflow lives. ci: rename branch-protection caller job id to branch-protection #146 (main) only needed change 1; beta needs both, which is why the two PRs are not identical diffs.

Worth noting for whoever merges: the diff cannot be validated by CI in the usual way, because the check it repairs is precisely the one that is not reporting. The evidence is the context-name mechanic above plus the fact that main and development already carry the corrected form.

No action from me — flagging only so this is not mistaken for a stale duplicate of #146.

[rubenvdlinde]

Closing as superseded — beta already carries this exact change.

.github/workflows/branch-protection.yml on beta declares the caller job id as branch-protection, which is identical to what this PR proposes, so the required status context branch-protection / check-branch already reports under the right name. The same check also finds zero references to the non-existent Conduction org in that file.

Verified by comparing the PR head against the base rather than by reading the title: both resolve to the same caller job id.

This is the same disposition as ConductionNL/pipelinq#685, which was the first of this family I looked at and where the branch had additionally gone stale by 571 commits. Nothing here needs carrying forward.

Note that the sibling PR targeting main is not superseded — main still declares the job id as check — so that one stays open on its own merits.