fix(version): exit with code 1 when no unreleased changesets found - #1860

…1995)

* ci(release): upgrade changesets/action to v2 for @changesets/cli v3

@changesets/cli v3 no longer prints the "New tag: <pkg>@<version>" lines that
changesets/action v1.9.0 scraped to learn which packages were published. The
action therefore saw zero published packages: it pushed no git tags, created no
GitHub releases, and set published=false -- while npm publishing itself
succeeded. 3.6.0 reached npm with no GitHub release history because of this,
and the publish step still reported success.

Two v3 breaking changes combined to produce the failed run:

- Published-package detection moved from stdout parsing to a shared output file
  named by CHANGESETS_OUTPUT (changesets/action#678). Action v1 has no such
  support and reported published=false, which skipped tagging and releases and
  also un-gated the canary step below.
- `changeset version` now exits 1 when there are no unreleased changesets
  (changesets/changesets#1860); v2 exited 0 silently. That turned the
  un-gated canary step into a hard job failure.

Upstream treats these as a matched pair and action v2 validates it, refusing
CLI v2 (changesets/action#699). There is no equivalent check in v1 for CLI v3,
which is why the mismatch degraded silently instead of failing fast.

Changes:

- changesets/action v1.9.0 -> v2.1.2, using v2's renamed kebab-case inputs and
  passing the app token through the `github-token` input, which is now required
  for custom tokens. `commitMode: github-api` is dropped because v2 uses the
  GitHub API by default.
- Guard both canary steps on the presence of changeset files, so an emptied
  .changeset/ is a clean skip rather than exit 1.
- Add a step asserting that the version present on npm has a matching git tag,
  so a silent tagging failure fails the job instead of reporting success.
- Remove scripts/print_release_version.sh and its step. Its output was read
  nowhere in the workflow, its exit code was swallowed by the surrounding
  command substitution, and it ran `changeset version` followed by
  `git reset --hard` inside the release job.

Co-Authored-By: Claude Opus 5 <[email protected]>

* ci(release): trim the comments added with the changesets v2 upgrade

The explanatory blocks restated the commit message and PR description, which
git blame already reaches, and ran six to eight lines in a file whose idiom is
one- to three-line constraint notes. Keep only what is not visible in the code
and would be re-broken if removed: that the action and CLI majors move
together, that the tag check is deliberately independent of the action's own
report, and why the canary steps test for changeset files before versioning.

Co-Authored-By: Claude Opus 5 <[email protected]>

---------

Co-authored-by: Claude Opus 5 <[email protected]>