chore(firestore-bigquery-export): bump firebase-admin to ^14.2.0

[cabljac]

First layer of the Cloud Tasks write buffer stack. Bumps firebase-admin from ^13.6.0 to ^14.2.0 and the change tracker from ^2.1.0 to ^2.2.1, regenerates the shrinkwrap, and adds one override; no source changes. The admin bump also moves @google-cloud/firestore from 7.11.6 to 8.7.1, a major on the client the tracker's backup writes go through.

The next layers enqueue onto a task queue by bare function name. firebase-admin 14.2.0 resolves the deployed kit-<instance id>- prefix itself from FIREBASE_KIT_INSTANCE_ID, which the Firebase CLI sets on every deployed kit function from 15.28.0, so the kit does not have to reconstruct the prefix.

Tracker 2.2.0 (#3133, #3134) is the first release that runs on firebase-admin 14: earlier versions pinned admin 13 and used the namespaced API, so npm nested a second admin copy under the tracker with no default app and every backup write failed. 2.2.1 (#3137) adds the view-update project fix from #3120. The shrinkwrap now holds a single firebase-admin@14.3.0, verified by resolving firebase-admin/firestore from the tracker's directory and calling getFirestore after the kit's initializeApp. The kit pins firebase-functions ^7.3.3-rc.0, which no stable range in the tracker can match, so a root overrides entry pins the tracker's firebase-functions to the kit's own; the shrinkwrap holds a single firebase-functions@7.3.3-rc.0 as well, so tracker log lines keep the kit's trace context. That single-copy guarantee reaches consumers through the published shrinkwrap and holds for npm installs only: npm ignores overrides from a non-root package, and pnpm and yarn ignore a dependency's npm-shrinkwrap.json, so they resolve the tracker's ^6.3.2 || ^7.3.0 to a second firebase-functions copy.

62 unit tests and tsc -b pass on this layer; 89 on the top of the stack. The top of the stack was also deployed to a test project with Firebase CLI 15.29.0: afterFirstDeploy provisioned the dataset, changelog table, and view; create, update, and delete events landed in the changelog; a redeploy exercised the update-view path with the project preserved; and with the changelog table removed, the trigger enqueued onto syncBigQuery, the tracker wrote backup documents through admin 14 / firestore 8.7.1, and the queue drained without duplicate rows once the table was re-provisioned.

Part of #3031.

[gemini-code-assist]

Code Review

This pull request updates the firebase-admin dependency from ^13.6.0 to ^14.2.0 in kits/firestore-bigquery-export/package.json and updates the lockfile accordingly. However, this upgrade introduces a dual-instance hazard because @firebaseextensions/firestore-bigquery-change-tracker still depends on v13. This mismatch can lead to runtime errors since the nested v13 instance used by the change tracker will remain uninitialized. To resolve this, the change tracker should be updated to support v14, or the initialized Firebase instance should be passed directly to the tracker.

[IzaakGough]

Approving. Checked the shrinkwrap holds single copies of firebase-admin@14.3.0 and firebase-functions@7.3.3-rc.0 with no nested tracker copies, and confirmed the override is genuinely required: tracker 2.2.1 declares firebase-functions: "^6.3.2 || ^7.3.0", which a prerelease 7.3.3-rc.0 cannot satisfy under semver. Also confirmed npm does not record overrides in the lockfile, so its absence from the shrinkwrap root entry is expected rather than a stale lock.

The motivating behaviour is real: firebase-admin/lib/functions/functions.js reads FIREBASE_KIT_INSTANCE_ID in the task queue scope resolution. And the kit source only imports firebase-admin/app and firebase-admin/eventarc, both stable across the v14 major, so "no source changes" holds.

Three notes inline, none blocking.