Fix: map the ADK log level to a legal gcloud verbosity in deploy cloud_run

[AmaadMartin]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

2. Or, if no issue exists, describe the change:

Problem: adk deploy cloud_run --log_level warn always fails. The ADK CLI accepts debug|info|warn|error, but gcloud's --verbosity accepts critical|debug|error|info|none|warning. prepareGCloudArguments forwarded the ADK level verbatim, so gcloud rejected --verbosity warn during argument parsing and the deploy aborted before it reached GCP. The user only saw Failed to deploy to Cloud Run: Command failed with exit code 2, which does not name the log level as the cause.

Solution: I translate the ADK log level to a gcloud verbosity at the single point of use. The lookup falls back to info for any value outside the ADK vocabulary, so the argv can never carry an illegal verbosity. I chose a fallback over a throw for two reasons: a throw replaces one broken deploy with a different broken deploy, and the ADK CLI already resolves an unrecognized log level to INFO everywhere else (cli.ts:47). The translation happens at the gcloud boundary only, so the generated Dockerfile keeps the raw ADK level for the ADK server inside the container.

Notes for the reviewer:

• Behavior change beyond the fix. --log_level warning, critical and none are not ADK log levels, but they are legal gcloud verbosities, so today they reach gcloud unchanged. They now fall back to info. This is intentional: those values already resolve to INFO for the ADK server itself, both locally and in the container, so the gcloud verbosity and the agent log level now agree instead of diverging. debug, info and error produce byte-identical argv.
• Collision check. I listed all open PRs on the fork and diffed the six that touch dev/src/cli/deploy/cli_deploy_cloud_run.ts or dev/src/cli/cli.ts (Fix: merge user --labels into the single gcloud labels flag in adk deploy cloud_run #696, Fix: expose --otel_to_cloud on adk deploy cloud_run #694, Fix: forward --session_service_uri and --artifact_service_uri into the Cloud Run Dockerfile #588, Fix: document the gcloud pass-through of adk deploy cloud_run in --help #587, Fix: validate --log_level against a closed vocabulary and stop discarding LogLevel.DEBUG #592, Fix: derive cloud_run pass-through gcloud args from the commander parser, not raw process.argv #447, Fix: honor a caller-supplied appName in deployToCloudRun (|| / ternary precedence) #354, Fix: pin the generated Dockerfile to an explicit Node LTS major #540, Fix: exit non-zero when adk deploy fails #455). None of them adds or edits a --verbosity line, so this branch is cut from main rather than stacked. Fix: validate --log_level against a closed vocabulary and stop discarding LogLevel.DEBUG #592 is the closest neighbour: it validates --log_level in cli.ts. It is complementary, not overlapping, because warn is a valid ADK level that gcloud still rejects.
• No new exports, no new dependencies, no signature changes.

Testing Plan

Please describe the tests that you ran to verify your changes. This is required for all PRs that are not small documentation or typo fixes.

Unit Tests:
[x] I have added or updated unit tests for my change.
[x] All unit tests pass locally.

npx vitest run --project unit:dev dev/test/cli/cli_deploy_cloud_run_test.ts -> 34 passed. I added 7 cases and edited none of the 27 existing ones.

Coverage. The new code (the table at cli_deploy_cloud_run.ts:60-69 and the call site at :104) has 100% line and branch coverage; both sides of the ?? are exercised. The file as a whole reports 95.53% statements / 89.13% branches. The shortfall is entirely pre-existing uncovered code (lines 74, 119, 152-155, 187, 191) that this change does not touch.

Proof the tests can fail. I ran each new test against mutated source and confirmed it fails.

Mutation	Tests that failed	Message
Restore options.logLevel.toLowerCase() on the --verbosity line	warn->warning, upper-case, unknown-level fallback	expected 'warn' to be 'warning', expected 'trace' to be 'info'
Translate by assigning the result back into options.logLevel	Dockerfile keeps the raw level	expected '\nFROM node:lts-alpine...' to contain '--log_level='warn''
Change the table entry to 'debug': 'critical'	debug passthrough	expected 'critical' to be 'debug'
Drop the ?? 'info' fallback	unknown-level fallback	expected undefined to be 'info'

The second mutation is the one worth calling out: it is the in-place variant that looks idiomatic here, because the function already mutates options.project and options.region. It would leak the gcloud spelling into the container command line, and that test is the guard against it.

Manual End-to-End (E2E) Tests:

The failure is in argv construction, and gcloud validates --verbosity during argument parsing, before authentication. So this reproduces offline with no GCP project. Against Google Cloud SDK 579.0.0:

$ gcloud version --verbosity=warn
ERROR: (gcloud.version) argument --verbosity: Invalid choice: 'warn'. Did you mean 'warning'?
$ echo $?
2

$ gcloud version --verbosity=warning
Google Cloud SDK 579.0.0
$ echo $?
0

The full choice list comes from the same SDK: gcloud version --verbosity=bogus reports Valid choices are [critical, debug, error, info, none, warning].

To exercise the CLI end to end: npm install && npm run build, then adk deploy cloud_run --project any-project --region us-central1 --log_level warn ./path/to/agent. Before this change the deploy aborts on the rejected argument; after it, gcloud accepts the argv and proceeds.

Checklist

[x] I have read the CONTRIBUTING.md document.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have added tests that prove my fix is effective or that my feature works.
[x] New and existing unit tests pass locally with my changes.