fix(build): name canaries above every published release of their major

[armando-navarro]

Fixes #3779

ng add @angular/fire@canary now installs the newest canary build instead of the release candidate, and keeps doing so after 21.0.0 ships.

Changes

• tools/canary-version.js picks the version a canary is named after: one patch above the highest published version of the same major that is not a canary, or package.json's version without its prerelease part if that is higher.
  • Today that gives 21.0.1-canary.<UTC commit time>.sha-<short sha>.
  • After 21.0.0 ships it gives 21.0.1-canary.*, and after 21.0.1 ships, 21.0.2-canary.*.
  • With package.json at 22.0.0-rc.0 and nothing in 22 published yet, it gives 22.0.0-canary.*.
• tools/build.sh reads the published versions with npm view @angular/fire versions --json and stops the build if npm can't be read. Tagged releases are named exactly as before.
• tools/canary-version.jasmine.ts covers the cases above, and tsconfig.jasmine.json now includes tools/**/*.jasmine.ts so test:node runs it.
• The warning about a prerelease in package.json is removed, since a prerelease there no longer changes the name.

Behavior to know

• Someone on a 21.0.1-canary build isn't offered 21.0.0 by ng update once it ships, because 21.0.0 ranks below what they have. To go back to a release they install it directly, for example npm install @angular/fire@21.
• A canary built while a release is publishing can be named at that release's version and rank below it until the next canary build.

Verification

• npm run test:node: 342 specs, 0 failures. Counting published canaries again fails 1 spec, and using semver.inc on the release candidate (which turns 21.0.0-rc.1 into 21.0.0) fails 5.
• Ran tools/build.sh in a scratch repository with npm view answering from version lists and the build step stubbed:
  • Today's npm versions give 21.0.1-canary.*.
  • Adding 21.0.0 gives 21.0.1-canary.*, adding 21.0.1 gives 21.0.2-canary.*.
  • Adding 21.1.0-rc.0 gives 21.1.1-canary.*, adding 21.0.1-rc.0 gives 21.0.2-canary.*.
  • Adding earlier 21.0.1-canary.* builds still gives 21.0.1-canary.*.
  • Adding 20.0.4 or 22.0.0-rc.0 doesn't change the 21 canary.
  • With npm unreachable the build stops with an error.
• With npm's version picker (npm 10.9.8) in each of those states, ^<canary> selects the canary, and ^21.0.0, ~21.0.0, ^21.0.0-rc.1 and ^20.0.0 never select a canary.

[tyler-reitz]

LGTM.

Ran test:node at 6deb73a (342 specs, 0 failures) and checked the new spec can fail: restoring the old naming rule turns 7 of its 8 specs red, so it guards the bug rather than the implementation. Also ran build.sh with npm view stubbed, and the base version tracks the published list as described, including exit 1 when npm is unreachable.

One non-blocking note for "Behavior to know": canary followers drop off the canary channel at every patch release, not just at 21.0.0. With ^21.0.1-canary.X saved, once 21.0.1 ships the range resolves to 21.0.1 even if a 21.0.2-canary.* exists (checked with node-semver 7.7.3), since a prerelease only satisfies a range on its own major.minor.patch tuple. Worth a line, since that is the ongoing effect for anyone tracking canary.