Add support for Build Envvars and Secrets

[falahat]

Description

Lets Cloud Run deployments pass env vars and secrets to the build. They're read from the service's firebase.google.com/buildConfig.environmentVariablesAndSecrets annotation, a JSON object. The annotation is a prototype: where this config finally lives is out of scope for now.

Values follow apphosting.yaml:

• Strings. Numbers and booleans also work and become strings (3 becomes "3"), as they do in apphosting.yaml.
• Secrets: {"secret": "npm-token"}, {"secret": "npm-token@3"}, or a full resource name.

Only local builds can use secrets: they read them with the deployer's credentials, through App Hosting's loadSecret. Cloud Run's build API only takes plain values, so if the annotation names a secret, a deploy that builds on Cloud Build fails and points to "localBuild": true. Per the spec, there's no --allow-local-build-secrets flag.

• buildEnv.ts: parses and validates the annotation.
• prepare.ts: reads it, and rejects secrets for builds on Cloud Build.
• deploy.ts: passes only the non-secret values to Cloud Build, and all of them to local builds.

Stacked on #11207. Next is #11208 (SDK auto-init).

Scenarios Tested

• Unit tests.

Sample Commands

gcloud run services describe my-service --region us-central1 --format export > service.yaml
# Add this under metadata.annotations in service.yaml:
#   firebase.google.com/buildConfig.environmentVariablesAndSecrets: '{"API_URL": "https://api.example.com", "NPM_TOKEN": {"secret": "npm-token@3"}}'
gcloud run services replace service.yaml
firebase deploy --only run:my-service

[gemini-code-assist]

Code Review

This pull request introduces support for build-time environment variables and secret references on Cloud Run services by reading them from a service annotation, validating them, and passing them to either Cloud Build or local builds. The review feedback highlights two TypeScript type-safety issues: first, an unsafe type assertion (as Record<string, string>) in deploy.ts should be replaced with explicit filtering of string values to adhere to the repository style guide; second, a compilation error in buildEnv.ts when calling Object.entries on an unknown type should be resolved by casting the validated object to Record<string, unknown>.