Declarative security: first deploy with a fresh managed SA fails with 404 actAs (no propagation wait or retry)

[cabljac]

Description

Deploying a codebase with requireRoles on a project with no existing managed service account creates the SA, grants roles, then immediately calls createFunction. IAM SA creation is eventually consistent, so GCF rejects the brand new SA:

i  functions: Creating managed service account firebase-fn-5873801311@<project>.iam.gserviceaccount.com...
i  functions: Granting IAM roles to firebase-fn-5873801311@<project>.iam.gserviceaccount.com...
⚠  functions: Request to .../functions?functionId=... had HTTP Error: 404, Service account
   projects/-/serviceAccounts/firebase-fn-5873801311@... was not found. ... verify that the caller
   has been granted the 'iam.serviceAccounts.actAs' permission.

The SA does exist (visible in console immediately after). There's currently no mitigation on either side:

• grantNewRoles creates the SA and returns without polling for visibility (src/deploy/functions/release/fabricator.ts:98-118), and applyPlan goes straight into function creates (fabricator.ts:210-212)
• the 404 is never retried: DEFAULT_RETRY_CODES = [429, 409, 503] (src/deploy/functions/release/executor.ts:22), and createV2Function's catch only special-cases Cloud Run RESOURCE_EXHAUSTED before rethrowing as DeploymentError (fabricator.ts:557-571)

Steps to reproduce

1. Project with no firebase-fn-* SA, codebase using requireRoles
2. firebase deploy --only functions
3. SA is created and roles granted, then every function create fails with the 404 above

Failing tests reproducing both facets (createFunction 404 never retried, getServiceAccount never polled after create) are up as a draft PR: #10858.

Is the intended fix to poll the SA for visibility after creation, to retry this specific 404 on the create path, or both? Terraform and gcloud both sleep-retry here, and a visibility poll alone may not be enough since GCF's own actAs check can lag behind IAM reads.

[cabljac]

Related: #10860, which is what turns this from a one-deploy hiccup into an SA-per-deploy leak.

[cabljac]

Did a deeper verification pass, three additions:

1. The error wording supports propagation as the root cause: IAM returns NOT_FOUND for a not-yet-visible SA, whereas a genuine actAs gap returns PERMISSION_DENIED. The "was not found" in the log is the former.

2. The "still fails on redeploy" part of the report is explained by Declarative security: failed first deploy orphans the managed SA, every retry creates a new one #10860 compounding with this: each redeploy mints a fresh SA and immediately races its propagation again, so the deploy never gets a chance to hit an already-propagated SA. The two bugs jointly reproduce the reported symptom, no additional cause needed.

3. On the fix question, one refinement: a blanket 404 retry on the create path is probably too broad (404 can also mean a genuinely deleted SA), so scoping it to deploys where the CLI just created the SA (fabricator already knows via plan.serviceAccountToCreate) with a bounded backoff, or a visibility poll in grantNewRoles, avoids masking real errors.

Related preflight gap we noticed while verifying: nothing grants or checks iam.serviceAccounts.actAs on the managed SA for the deployer. checkServiceAccountIam (src/deploy/functions/checkIam.ts:33-59) only covers the default appspot SA, and the preflight in prepare.ts:166-170 tests setIamPolicy/serviceAccounts.create but not actAs. Owner/Editor deployers are fine, but a deployer with a custom role holding create+setIamPolicy and no actAs would fail persistently with PERMISSION_DENIED after the SA is created. Happy to split that into its own issue if you'd rather track it separately.