Cloud Run secrets: Secret Manager env injection done right

Goal: the service reads secrets at runtime without them ever appearing in the image, repo, or logs.

Deploy:
```
gcloud run deploy [SERVICE] --image [IMAGE] --region [REGION]   --set-secrets [ENV-VAR]=[SECRET-ID]:[VERSION]   --service-account [RUNTIME-SA]
```
VERSION can be `latest` or a number. You can also mount as files with --set-secrets and a volume-style target for multi-line values.

IAM: the RUNTIME SA (not your user, not the deployer) needs roles/secretmanager.secretAccessor on each secret.

Traps:
- Granting secretAccessor to the deployer identity instead of the runtime SA. Deploys succeed; the service crashes on boot reading the secret.
- `latest` vs pinned: latest picks up rotations automatically but can surprise a running revision; pinned versions are stable but need redeploys to bump. Choose per secret, deliberately.
- Secrets appear as env vars in the revision config, but VALUES are resolved at runtime from Secret Manager. Still, treat revision YAML as sensitive.
- Updating a secret value does not redeploy the service. If you pinned a version, bump the pin and redeploy. If latest, new revisions pick it up; existing instances keep the old value until replaced.
- Never echo secrets in build or startup logs. Not even "first 4 chars".

Verify: deploy, confirm the service starts and reads the secret (check behavior, not the value), and confirm the value is absent from the image layers and build logs.