fix(functions): keep sharing one source build across function deploy retries

[ajperel]

Description

Functions deployed to the same region share one source build: the first function builds from source, and the rest wait for its source token and reuse that build. Since #11044, any retryable error on the first function (for example a quota error or a service account propagation delay) abandoned that shared build. Every waiting function then built from source in parallel, even when the retry succeeded, which slows down large deploys and uses more build quota.

Waiting functions now stay on the shared build while the first function retries. Only a terminal failure of the function that is building releases them. SourceTokenScraper.withToken now wraps the whole retried deploy, and the token is fetched at the start of each attempt, so tokens that expire during a backoff are still refreshed. This change also:

• Stops a failed build from being treated as a finished shared build.
• Gives the v2 Cloud Run quota delete-and-recreate the executor's backoff and retry limit instead of an unbounded loop.
• Stops v2 deploys from waiting on a shared build when functionsv2deployoptimizations is disabled.

Scenarios Tested

• Unit tests for SourceTokenScraper and Fabricator cover the paths that decide whether a build is shared:
  • The first function retrying and then succeeding, or exhausting its retries.
  • Failures from other functions while a build is in flight.
  • Token expiry during retries.
  • Failed operations with and without a token.
  • Cloud Run quota retries.
  • The disabled experiment.
• Checked that each new test fails when the fix it covers is reverted.
• npm run test.
• Manually deployed a codebase with many functions in one region.

Sample Commands

firebase deploy --only functions

[gemini-code-assist]

Code Review

This pull request resolves an issue where retrying an initial Cloud Functions deployment could cause subsequent functions in the same region to build in parallel without a shared source token. This is achieved by swapping the order of scraper.withToken and this.functionExecutor.run in fabricator.ts, ensuring that waiting functions remain blocked on the scraper while the first function retries transient errors. Comprehensive unit tests have been added to fabricator.spec.ts to verify this behavior for both v1 and v2 functions during creation and updates. No review comments were provided, so there is no additional feedback.