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)".

Note for reviewers

src/schematics/update/v21/index.ts uses explicit .js-suffixed relative imports where v7/index.ts does not. This is intentional: the dedicated jasmine spec imports the migration directly under ESM, which requires the suffix. Please do not "fix" it back to match v7.

[tyler-reitz]

Approve. Good semver handling; subset over intersects correctly catches ranges like >=11 that intersects would miss, and non-semver specifiers (workspace:*, git URLs) are left alone with a warning rather than mangled. The constant-drift test against src/package.json is a nice guard against the two values silently diverging later.

Minor: v21/index.ts uses explicit .js-suffixed imports where v7/index.ts doesn't, worth a one-line note in the description so it doesn't get "fixed" back to match v7 (it's needed for the dedicated jasmine spec to import it directly under ESM).

[armando-navarro]

Thanks. I've added a reviewers note to the description explaining that the .js-suffixed imports in v21/index.ts are intentional (the jasmine spec imports the migration directly under ESM and needs the suffix), so they don't get reverted to match v7.