test: exercise real firebase-functions majors in CI, not just the pinned devDep

[cabljac]

Context

#310 happened because firebase-functions@7.x changed the emitted wrapper shape (rest-param functions, run.length === 0) and nothing in CI noticed: devDeps pin firebase-functions: ^4.9.0, so the suite only ever runs against 4.9.0 while the peer range allows >=4.9.0.

The regression test added in #311 simulates the v7 shape with hand-built mocks. That's the right thing for a unit test, but mocks encode our belief about the dependency's shape; if a future major changes the shape again, the mocks stay green while wrap() breaks for users, same failure mode as #310.

Proposal

Add a CI matrix dimension installing multiple firebase-functions majors (at minimum: lowest supported 4.9.0 and latest 7.x) and run the unit + integration suites against each. Alternative: a second install step swapping in latest before a re-run.

Detection-focused: the goal is that the next arity/shape drift in firebase-functions fails a build here instead of shipping.

[cabljac]

Some findings from investigating this locally, and a proposed shape.

What we verified: on firebase-functions@7.2.5 all the wrap()/wrapper-shape tests (the ones this issue exists to protect) pass. The only failures are the two #mockConfig tests, because functions.config() is removed in v7 (typed never, throws at runtime). Separately, compiling the specs against v6/v7 typings fails on a nested @types/express lib-check conflict, so a naive matrix leg can't even build without a skipLibCheck or devDep policy change.

Proposed shape, three parts:

1. Compile-then-swap rather than recompiling per version: compile specs once against the pinned 4.9.0, swap in the newer firebase-functions, run mocha on the compiled output. This mirrors how firebase-functions-test@3.4.1 misdetects v2 callables #310 actually hit users (their compiled code, new runtime shapes underneath) and sidesteps the type conflicts without touching tsconfig policy.

2. Don't skip the mockConfig tests on v7, assert the failure: mockConfig should detect firebase-functions >= 7 and throw a clear "functions.config() was removed in v7, migrate to params" error, and the v7 leg asserts that throw. Skipping would make the matrix pretend mockConfig works on v7 when it can't; with the throw, the >=4.9.0 peer range's promise becomes true again, everything either works or fails loudly with migration guidance.

3. Pinned majors gate PRs, floating latest doesn't: required per-PR legs for 4.9.0 and ^7, plus a scheduled canary against latest that doesn't block merges. Otherwise the day v8 ships, every open PR here goes red for unrelated reasons.

Scope: unit job only to start, the integration job exercises the same wrap surface through the emulator for no extra signal.

That makes this three small PRs: the mockConfig throw + tests, the matrix, the canary job.

[IzaakGough]

Thanks for raising this! We will investigate as soon as possible.