GeezerVison

Fixes #3766

These changes take us back to the release candidate pattern this repo used up until #3674, after which @angular/fire@next started resolving to a canary build instead of the release candidate.

Details

• The root package.json version field returns to 21.0.0, so a canary published from main is named 21.0.0-canary.<sha>, which ranks below every 21.0.0-rc.N.
  • Release candidates are published from their own git tag, which is where tools/build.sh takes a tagged release's version from.
  • This is how releases through v20 were cut.
• tools/build.sh also drops any prerelease part when naming a canary, and says so in the build log, so a prerelease written into that field again cannot produce a canary that outranks it.
• The comment and log line in src/schematics/common.ts no longer say a prerelease range matches canary builds, since it stops being true with this PR.
• The sample's tarball path follows the version field, becoming angular-fire-21.0.0.tgz.
• A second commit regenerates sample/package-lock.json, which still named the 21.0.0-rc.0 tarball, two releases behind its own package.json.

Verification

Every naming path was run against the real script.

• With the field at 21.0.0, a merge to main and a pull request build:
  • both produce 21.0.0-canary.95b3de1 on the canary tag
  • the tag 21.0.0-rc.2 publishes 21.0.0-rc.2 on next
  • the tag 21.0.0 publishes 21.0.0 on latest.
• With a prerelease left in the field, the build still succeeds and names the canary 21.0.0-canary.95b3de1, logging why.
• 21.0.0-canary.95b3de1 is selected by none of ^21.0.0-rc.1, ~21.0.0-rc.1, ^21.0.0-rc.2, ^21.0.0 or 21.x, and ranks below 21.0.0-rc.1.
• npm run test:node after a full build: 331 specs, 0 failures.
• The build produces angular-fire-21.0.0.tgz, and npm ci in sample/ succeeds against the regenerated lockfile, where it previously failed on the mismatch.