Declarative security: failed first deploy orphans the managed SA, every retry creates a new one

[cabljac]

Description

The managed SA is only rediscovered by reading serviceAccount off already-deployed endpoints (src/deploy/functions/prepare.ts:84-92). If the first deploy creates the SA and grants roles but function creation fails (e.g. #10859), there are zero deployed endpoints carrying it, so the next deploy finds no existingManagedSA and unconditionally mints a fresh random name via generateManagedServiceAccountName (prepare.ts:141-145, src/gcp/iam.ts:307-330).

Net effect: each failed deploy leaves behind a firebase-fn-<10digits> SA that nothing references, and the retry creates another one and grants the roles again. In our repro (storage-resize-images migration) a few retries produced several orphaned SAs, each holding Storage Admin and roles/aiplatform.user at project level. There's no cleanup path, so unused SAs with broad grants accumulate in the project IAM policy, which seems worth treating as a security issue as well as a correctness one.

Steps to reproduce

1. Deploy a requireRoles codebase where function creation fails after SA creation (Declarative security: first deploy with a fresh managed SA fails with 404 actAs (no propagation wait or retry) #10859 reproduces this reliably)
2. Re-deploy
3. CLI logs Creating managed service account firebase-fn-<new number>... again; repeat for as many SAs as you like

A failing test reproducing this (empty have backend, SA already in project, new name generated anyway) is in draft PR #10858.

On the fix: should discovery fall back to looking up existing firebase-fn-* SAs in the project (the description already embeds the codebase, so they're identifiable, though gcp/iam.ts currently has no list API), or would you rather make the name deterministic per project+codebase so a retry converges on the same SA? The deterministic route also removes the need for the collision loop in generateManagedServiceAccountName.

[cabljac]

Two additions from a deeper verification pass:

1. There's a second path to the same orphan that doesn't involve Declarative security: first deploy with a fresh managed SA fails with 404 actAs (no propagation wait or retry) #10859: if createServiceAccount succeeds but the role grant fails (fabricator.ts:126-138 rethrows and aborts the deploy), the SA is already created and nothing rolls it back. So any failure between SA creation and a successful function create leaks one.

2. Orphans are never garbage-collected: removeOldRoles (fabricator.ts:153-195) only ever deletes the SA discovered from deployed endpoints on unenroll, so SAs leaked by failed deploys are invisible to it. Combined with Declarative security: first deploy with a fresh managed SA fails with 404 actAs (no propagation wait or retry) #10859 this loops - each retry leaks one more SA holding all the requireRoles project-level grants, which is the security-hygiene angle from the description getting worse per attempt.

[inlined]

Thoughts:

1. Let's add a best effort cleanup when all functions fail to deploy
2. Let's see if it's reasonable to ensure that the label is up to date in case a codebase changes name (will not do if it requires additional permissions, or will fail gracefully)