fix(ci): derive release outcome from git tags, not publish log prose

[ifaouibadi]

release.yml decided whether a release had happened by grepping the publish output for New tag:. changesets 3.0.1 does not emit that string, so a fully successful publish produced an empty match, was classified none, and the tag push, GitHub Release and summary steps were all skipped — while every package did reach the registry.

What changed

• The published set is now read from the git tags changesets creates, diffed around the publish call, instead of from log prose.
• A zero exit whose log reports published packages but produced no new tags now fails the job rather than being read as none. That is the tripwire: a changesets upgrade that stops tagging goes red instead of silently losing another release's tags.
• Push tags pushes the derived tag list explicitly. changesets creates lightweight tags, which git push --follow-tags does not push — so that step would have pushed nothing even when it did run.
• The failure summary no longer asserts that nothing reached the registry, since that is not true of the new tripwire branch.

The non-zero-exit-goes-red behaviour added previously is unchanged and covered below.

Verification

The run: scripts were extracted from this workflow and executed against a stubbed pnpm changeset publish in a throwaway git repo — 11 assertions, all passing:

scenario	result	step exit
packages publish (tags created)	published	0
nothing to publish	none	0
publish exits non-zero	failed	1
log says published, no tags created	failed	1

Plus: the push step consumes the emitted list and calls git push origin <tag> <tag>, and an empty list exits 1 rather than pushing nothing.

Targeted at @changesets/cli 3.0.1, pinned in a comment at the publish step and enforced by the tripwire above.

[github-actions]

Thanks for the pull request — it is in the queue and a maintainer will review it.

This repository is maintained on a weekly cadence. Anything opened from outside gets
a human reply within 2 business days; this comment is automation confirming your
pull request landed, and it is not that reply.

What happens next:

• CI runs on the pull request. Check, Build and Test need to be green before
  review — you can push fixes straight to the same branch.
• A maintainer reviews it against CONTRIBUTING.md.
• A change to a package's public API, or a new dependency, needs a maintainer
  decision before it can merge. That is where the call gets made rather than a
  delay, and we will tell you either way instead of leaving it open.

If this is a security fix for an unreported vulnerability, please close it and use
the private channel first — SECURITY.md.
A public pull request describes the flaw to everyone before the fix is released.