fix(schematics): align the workspace firebase dependency with the supported range

[armando-navarro]

Checklist

• Issue number for this PR: ERROR FirebaseError: Expected type '_Query', but it was: a custom _CollectionReference object in 21.0.0-rc.0 #3684 (also Type Error: toDate() not found on Timestamp fields in 21.0.0-rc.0 #3681 and ERROR InternalError: too much recursion in 21.0.0-rc.0 #3682; all three share the root cause this PR addresses. Referenced with Refs rather than Fixes: no published build carries the change until the next release is cut or a canary is published, so the issues should close when reporters can actually install the fix.)
• Docs included?: No. The migration and ng add print a one-line explanation whenever they change anything, and the v21 upgrade documentation is tracked with the release notes.
• Test units included?: Yes (15 new specs: the alignment helper's range handling, warning behavior, both-dependency-sections handling, idempotency, a constant-sync check against src/package.json, and the migration's install-task behavior).
• In a clean directory, yarn install, yarn test run successfully? Yes; npm run build and the node test suites run green locally (55 specs), and the migration was verified end-to-end against a packed build (below).

Description

Upgrading an app to @angular/fire 21 while its own package.json still requests firebase@11 produces an install with two copies of the firebase SDK: npm keeps 11 at the root and nests 12 under @angular/fire. No install-time error fires, and the two copies reject each other's objects at runtime. #3684, #3681, and #3682 are all this one failure (analysis and reproductions in those threads).

This PR makes the schematics keep the workspace's firebase entry aligned with the range the library requires:

• a shared alignFirebaseVersion helper and firebaseVersionRange constant in src/schematics/common.ts;
• ng add writes the entry when missing and realigns an incompatible one before its install task runs;
• a new migration-v21 runs the same alignment during ng update @angular/fire, scheduling an install only when it changed something (the CLI re-runs the migration on rc-to-stable updates, so the no-op path matters).

Behavior details:

• A range is rewritten only when it is not entirely inside ^12.4.0 (semver.subset); intersects would keep ranges like ^12.0.0 or >=11 that a stale lockfile still resolves below the required floor.
• Non-semver specifiers (dist-tags, workspace:, file:, git URLs) are never rewritten; the user gets a warning explaining the risk instead.
• firebaseVersionRange intentionally duplicates dependencies.firebase from src/package.json instead of being injected at build time: the build's version-injection machinery (versions.json) is under discussion in The ANGULARFIRE2_VERSION build placeholder ships unreplaced in the library, and versions.json never reaches the compiled schematics #3715, so the constant is the minimal bridge that machinery can later supersede. A spec reads src/package.json and fails the suite if the two values ever drift.

Verified end-to-end against a packed build. A fixture app with firebase@11.8.0 installed next to this package (the exact broken tree from the linked issues), then ng update @angular/fire --migrate-only --from=20.0.1:

❯ Align the workspace's firebase dependency with the range @angular/fire 21 requires,
  so the install cannot contain two copies of the firebase SDK.
    Updated the firebase version in your package.json from ^11.8.0 to ^12.4.0, the range
    @angular/fire requires; a workspace range outside it can leave the install with a
    second copy of the firebase SDK, which fails at runtime.
UPDATE package.json (400 bytes)
✔ Packages installed successfully.

npm ls firebase afterwards shows a single firebase@12.16.0, and a second run reports "Migration completed (No changes made)".