ci: guard production's version instead of requiring a Release-As pin

[finalerock44]

promotion-pin was guarding the wrong thing and blocked release-please's own Release PR, which has no pin by design (#185).

The 5.6.0 failure was not tag reachability: release-please anchored correctly on v5.5.0 from the manifest, then read production's package.json as the current version and logged updating from 5.6.0-beta.1 to 5.6.0-beta.1. The prerelease came in on the promotion merge, not from a tag.

So assert what actually matters — a PR into production must leave package.json on a plain X.Y.Z. npm-publish.yml checks the same thing, but only after the tag and release exist.

What & why

Type of change

• fix — bug fix
• feat — new feature
• perf — performance improvement
• refactor — code change that's neither a fix nor a feature
• docs — documentation only
• chore / ci / build / test — tooling, no user-facing change
• Breaking change (title has ! or PR notes a BREAKING CHANGE:)

Checklist

• PR title follows the Conventional Commits format (see comment above)
• pnpm lint passes
• pnpm typecheck passes
• pnpm build passes
• I have not bumped the version or edited CHANGELOG.md (release-please handles this)
• I have signed the CLA (the bot will prompt on first contribution)
• Docs / README.md / STYLE_GUIDE.md updated if behaviour or output changed

How to test

[claude]

Renaming this job orphans the required status check on the production ruleset.

This renames the job key promotion-pin → production-version. GitHub matches required status checks by name, and the in-file comment notes this gate "is required by the production ruleset":

dcd-cli/.github/workflows/cli-ci.yml

Lines 117 to 119 in a142328

	# version — so it does not need an exemption.
	production-version:
	if: github.event_name == 'pull_request' && github.base_ref == 'production'

Because the check reports under a new name after this merges, one of two things happens unless the ruleset is updated in lockstep:

• If the ruleset still requires promotion-pin, that context is never reported again — every promotion PR sits on "Expected — waiting for status" and becomes unmergeable.
• If nobody adds production-version to the required-check list, the new gate becomes advisory only — a promotion carrying a -beta version could be merged despite the check, which defeats the job's entire purpose.

Please update the production branch ruleset's required-status-check list from promotion-pin to production-version when this merges. (Not fixable in the diff — it's a repo setting — so no suggestion block.)