fix(ci): gate publishing on the registry, and bump actions off Node 20

[galangel]

Two independent CI fixes, one commit each so they can be reverted separately.

---

1. Gate publishing on the registry, not a git diff

check-version compared package.json at HEAD against HEAD~1. That made a version bump a one-shot trigger: when the publish that followed it failed, the bump was already consumed and no later push would ever retry it.

That single flaw stranded three versions, each behind a different publish failure:

version	bumped in	publish failed on
1.1.1	#16	expired npm token
1.2.0	#15	expired npm token
1.2.1	#18	npm 12 requiring Node ≥ 22

Each needed a fresh version number or a manual dispatch to escape. Now the gate asks the registry instead:

GET registry.npmjs.org/<name>/<version>
  200 → already published → skip
  404 → not there        → publish
  else → fail the job rather than guess

This is idempotent, so a failed publish simply retries on the next push — no stranding, no burnt version numbers.

Knock-on changes:

• workflow_dispatch no longer bypasses the gate. Bypassing would now mean attempting to republish an existing version, which npm rejects anyway. Dispatch still works for retrying without pushing.
• fetch-depth: 2 removed — no history needed.
• Outputs renamed to say what they mean: version_changed → should_publish, new_version → version.

Verified against the live registry

I extracted the step's script from the parsed YAML and ran it for real, rather than trusting it by inspection:

GET https://registry.npmjs.org/@galangel%2freact-tip-magic/1.2.1 -> 200
@galangel/react-tip-magic@1.2.1 is already published; nothing to do
  → version=1.2.1  should_publish=false

GET https://registry.npmjs.org/@galangel%2freact-tip-magic/9.9.9 -> 404
@galangel/react-tip-magic@9.9.9 is not on the registry; will publish
  → version=9.9.9  should_publish=true

Both branches behave correctly and the scope is URL-encoded properly as @galangel%2freact-tip-magic.

---

2. Bump actions off the deprecated Node 20 runtime

Every recent run warned that checkout, setup-node and action-gh-release target Node 20, which GitHub has deprecated and is already force-running on Node 24.

action	from	to
actions/checkout	v4	v7
actions/setup-node	v4	v7
actions/upload-artifact	v4	v7
actions/configure-pages	v4	v6
actions/upload-pages-artifact	v3	v5
actions/deploy-pages	v4	v5
codecov/codecov-action	v4	v7
softprops/action-gh-release	v1	v3

18 references across all three workflows. Several cross multiple majors, so I checked the inputs actually in use — token/files/fail_ci_if_error, name/path/retention-days, and tag_name/name/generate_release_notes/draft/prerelease — all stable across these ranges. No input changes were needed.

Also confirmed every referenced major tag resolves upstream (so nothing points at a tag that doesn't exist) and all three workflows still parse.

---

⚠️ What this PR's CI does and does not prove

Worth being explicit, because the coverage is uneven:

Workflow	Trigger	Verified here?
ci.yml	pull_request	yes — checkout, setup-node, upload-artifact all exercised
deploy-storybook.yml	push to main only	no
publish.yml	push to main / dispatch	no

So configure-pages, upload-pages-artifact, deploy-pages, action-gh-release and the new gate are not exercised until this lands on main. The codecov step is additionally gated on github.event_name == 'push', so codecov-action@v7 is untested here too.

The gate's logic is covered by the local run above. The storybook deploy and the release step are the two things to watch on the first push after merge.

Expected behaviour right after merge

The push will run Publish to npm, the gate will find 1.2.1 already published, and the publish job will skip — same visible outcome as before, but now for the correct reason. The next version bump publishes automatically without a dispatch.