fix(deploy): declare firebase-admin in the generated Cloud Functions manifest

[armando-navarro]

Checklist

• Issue number for this PR: The generated Cloud Functions manifest omits firebase-admin, so the deployed function crashes wherever peers are not auto-installed #3744 (required)
• Docs included?: no, none affected (dependency manifests only)
• Test units included?: no. The existing Node suite passes (117 specs). The fix was verified end to end: the generated ranges install under both plain npm install and --legacy-peer-deps and both function entry points load, while today's generated manifest under --legacy-peer-deps crashes with Cannot find module 'firebase-admin/app-check'.
• In a clean directory, yarn install, yarn test run successfully?: yes

Description

Fixes #3744.

Two dependency changes so the generated Cloud Functions manifest actually runs:

• Add firebase-admin: ^13.0.0 to the root package.json.
  • The build resolves the generated manifest's versions from the root package.json. With no entry there, firebase-admin resolved to undefined and was silently dropped from the manifest.
  • firebase-functions 6.x declares firebase-admin as a required peer and requires it eagerly at module load, so the deployed function crashed at cold start wherever the package manager did not auto-install peers (--legacy-peer-deps, yarn 1, pnpm).
  • ^13.0.0 because firebase-functions 6.x accepts ^11.10.0 || ^12.0.0 || ^13.0.0 and nothing newer (firebase-admin 14 is outside the range).
• Raise firebase-functions from ^6.1.0 to ^6.1.1.
  • 6.1.0's peer range excludes firebase-admin 13. 6.1.1 is the first release that accepts it, so the floor moves with the new entry.

These defects also affect the v20 line and are planned for cherry-pick onto the 20.0.x release branch after this lands.

[tyler-reitz]

LGTM, approving. Verified the core claim by replicating tools/build.ts and actions.ts against both branches: on main the generated manifest comes out as {"firebase-functions":"^6.1.0"} with firebase-admin absent, and with this PR both entries appear. The registry ranges check out too, including that ^6.1.1 resolves to 6.6.0 today and still peers on ^13.

One non-blocking suggestion, and it's the reason I'd rather see it in this series than later.

replaceSchematicVersions assigns root.dependencies[name] || root.devDependencies[name] with no guard (tools/build.ts:299, and the same shape at :296 for peerDependencies). When that resolves falsy, JSON.stringify drops the key and the package vanishes from every deployed function's manifest with no build error. The 0.0.0 placeholder in versions.json makes the entry look populated when it isn't, which is what made #3744 hard to spot.

A throw when the resolved version is falsy turns this from a broken cold start into a failed build. The peerDependencies loop is empty today, so nothing exercises it, which is exactly when this comes back.

[armando-navarro]

Thanks for replicating the manifest generation on both branches.

Your suggestion is implemented:

• replaceSchematicVersions now resolves every version through a helper that throws when the lookup comes back empty, naming the package
• Both loops go through it, including the empty peerDependencies one so the guard is already standing if that block ever repopulates.