fix(release): drop [skip ci] so the required check can run

[rubenvdlinde]

Closes the second half of #562.

The mechanism

The release job commits the version bump with [skip ci]. That marker suppresses every workflow on the pull request it then opens — including merge-hygiene.yml, whose job "Conflict markers and PHP syntax" is the single required status check on development in all 17 fleet repos:

$ gh api repos/ConductionNL/<app>/branches/development/protection \
    --jq '.required_status_checks.contexts'
["Conflict markers and PHP syntax"]

A required check that never runs is never satisfied. So the release PR parks at MERGEABLE/BLOCKED forever — auto-merge enabled, every check that did run green, and still unmergeable:

	openregister #2861	learniq #609
mergeable	MERGEABLE / BLOCKED	MERGEABLE / BLOCKED
auto-merge	SQUASH (enabled)	SQUASH (enabled)
checks	4, all SUCCESS	3, all SUCCESS
required check present	no	no

Only CodeQL reported at all — default-setup CodeQL ignores the marker. That's why these look green but never land.

This is the mechanism behind #562: the loop opens one PR per run and nothing ever closes them. Measured fleet-wide on 2026-08-26, 73 of the 74 green open PRs were release bumps in exactly this state.

The auto-merge guard added in #566 was working correctly — every release PR created today carries auto=YES. It simply had nothing to fire on.

The change

One line, plus the comments that justified it:

- git commit -m "chore(release): ${NEW_VERSION} [skip ci]"
+ git commit -m "chore(release): ${NEW_VERSION}"

The original reasoning — a one-number change in one XML file does not warrant a second full pipeline — was sound about cost and wrong about consequence. The cost objection is also weaker than it looked: these are public repositories, where Actions minutes bill at $0.

The suite now runs on the release PR, so it verifies the tree actually being tagged, the required check appears, and auto-merge completes on its own.