Add firebase-functions v7 CI leg; make mockConfig() throw on v7+

[cabljac]

Description

Refs #333 - implements the first two parts of the plan discussed there (the latest canary job is a follow-up and is intentionally not in this PR, so this does not close the issue).

1. mockConfig() now throws on firebase-functions v7+ (behavior change)

functions.config() was removed in firebase-functions v7 (it throws at runtime and is typed never). Previously mockConfig() would silently "succeed" on a v7 install while every subsequent config() read threw - a confusing trap. mockConfig() now detects the installed firebase-functions major version and fails at the mock site with migration guidance:

mockConfig() is not supported with firebase-functions v7+ because functions.config() was removed. Migrate to environment parameters using the params module.

Detection resolves the installed firebase-functions entry point and walks up to its package.json to read the version (the package's exports map does not expose ./package.json, on v4 or v7, so a plain require('firebase-functions/package.json') does not work). If the version cannot be determined, it falls back to feature-detecting config() on the v1 entry point.

Behavior on v4-v6 installs is unchanged.

2. CI matrix: unit tests run against both pinned firebase-functions and v7

The unit job gains a firebase-functions: [pinned, '7'] matrix dimension. The pinned leg is exactly today's flow. The 7 leg compiles the specs against the pinned devDependency, swaps in firebase-functions@^7 with npm install --no-save, and runs mocha on the already-compiled output. Compile-then-swap is needed because the specs do not compile against v6/v7 typings (nested @types/express lib-check conflict, plus config typed never), and it mirrors how users actually hit version drift (#310): their compiled code running against a newer firebase-functions.

The #mockConfig specs are version-aware: on the pinned leg they assert the existing mocking behavior; on the v7 leg they assert the new error (and that CLOUD_RUNTIME_CONFIG is left untouched). The two lifecycle env-restore tests seed CLOUD_RUNTIME_CONFIG directly on v7+ since their subject is cleanup(), not mockConfig(). Nothing is skipped on either leg.

Both legs are meant to be required checks - they target pinned majors, not floating latest, so they cannot go red from an unrelated upstream release. A scheduled non-blocking canary against firebase-functions@latest is the remaining part of #333.

Verified locally on Node 22:

• pinned (4.9.0): npm ci && npm test - 119 passing, 0 failing
• v7 (7.2.5): npx tsc, npm install --no-save firebase-functions@^7, npx mocha .tmp/spec/index.spec.js - 119 passing, 0 failing (v7 mockConfig assertions confirmed running), lint clean

Code sample

// with firebase-functions@^7 installed:
const test = require('firebase-functions-test')();
test.mockConfig({ slack: { url: 'https://...' } });
// throws: mockConfig() is not supported with firebase-functions v7+ because
// functions.config() was removed. Migrate to environment parameters using
// the params module.

[gemini-code-assist]

Code Review

This pull request adds support for detecting the major version of firebase-functions to handle the removal of functions.config() in v7+, causing mockConfig() to throw an error with migration guidance on newer versions. The feedback suggests making the version parsing more robust by using parseInt to prevent NaN results, and exporting a unified _isConfigRemoved() helper to ensure consistent detection logic across both the source code and the test suites.

[cabljac]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces changes to handle the removal of functions.config() in firebase-functions v7+. It adds detection logic to check the installed major version of firebase-functions and updates mockConfig() to throw a clear migration error when v7+ is detected. Test suites have been updated accordingly. The review feedback suggests caching the result of the _isConfigRemoved() check to avoid redundant file I/O and environment variable manipulation on subsequent calls.