fix(ci): choose a release's dist-tag when it publishes, and move next after it - #3794

Fixes #3790
Fixes #3791

The publish job now picks a release's dist-tag when it publishes, moves next up after a stable release, and waits until npm lists each publish before the next one starts.

Changes

The first commit moves the publish job's new steps into tools/publish-job.js and the version rules into tools/release-tag.js, each with a spec.

• A release's dist-tag chosen in a new step for GitHub Releases:
  • A stable version goes to latest only if it ranks above npm's latest and every other stable git tag. Git tags count because a higher release can still be in npm's publish-time scan.
  • Otherwise it goes to v<major>-lts, the name Angular uses for its own older majors.
  • The job fails instead if the version does not rank above the current v<major>-lts, or above another stable release of its own major.
  • A prerelease goes to next, as before.
• Waiting until npm lists each publish.
  • After npm publish, the job polls npm's dist-tags every 15 seconds for up to 20 minutes.
  • Canary and release publishes now share one npm-publish concurrency group, so the next publish starts only after the wait.
  • If the wait times out after a release on latest, the job fails and prints the command that moves next.
• Moving next.
  • After a release npm lists as latest, the job runs npm dist-tag add @angular/fire@<version> next through the publishing proxy when next is lower.
  • A failure prints the same command.
• Re-runs. A re-run of a release npm already lists skips npm publish and continues with the wait and the next move.
• tools/build.sh only sets the version now. The publish step passes the tag to npm publish, so publish.sh is gone.
• The job has a 30-minute timeout.

The second commit moves the existing canary check from #3784 into tools/publish-job.js, with the same decisions and messages, and runs it only for pushes and scheduled runs.

Behavior to know

• Release branches run their own copy of the workflow. 20.1.x needs this change before its next release, or that release still publishes to latest. A separate PR will bring it there. 20.0.x gets no further releases.
• The next move has not run for this repository before. The first release after this merges is its first real run. If it fails, the job prints the command to run by hand.
• A tagged prerelease still moves next, even below its current value.
• The concurrency group is renamed from canary-publish to npm-publish, so a canary still queued under the old name when this merges is not ordered with the first run under the new one.

Verification

• npm run test:node: 381 specs, 0 failures. The new specs cover:
  • the tag rules, including a comparison against semver over 50 version pairs
  • each step against a fake npm and git
  • the real git and $GITHUB_OUTPUT calls, against a local repository
• The concurrency queue and the publishing proxy can't be run locally. This PR's CI shows whether GitHub accepts the workflow file, and the publish job itself only runs on main and on releases.