fix(cli): reject multi-line project/region before they reach the GKE manifest

[prasanna8585]

Problem

Follow-up to #6930 / 8192d1b. As the reviewer on that PR noted: "the gke manifest still interpolates both unchecked, so a pull request for that would be welcome."

to_gke's deployment.yaml is built by raw f-string interpolation, not a YAML library with automatic escaping:

f'        - name: GOOGLE_CLOUD_PROJECT\n          value: "{project}"'
f'        - name: GOOGLE_CLOUD_LOCATION\n          value: "{region}"'

A newline embedded in project or region breaks out of the quoted YAML scalar the same way it broke out of a Dockerfile ENV line in #6930 — except deployment.yaml is kubectl apply'd directly to a real GKE cluster, so the blast radius is a live cluster resource, not a local build step.

Confirmed exploitable, not just malformed: a crafted region value can produce a deployment.yaml that a real YAML parser accepts as a Deployment whose pod spec has two containers — the legitimate one and a second, fully attacker-controlled, privileged sidecar with an arbitrary command. This isn't a parse-error DoS; it's accepted as valid, additional pod spec structure.

Fix

Generalizes the existing _validate_dockerfile_env_value (from 8192d1b) to _validate_no_newlines, since the underlying reason for the check — a value written into a line-based format where an embedded newline can contribute new, attacker-controlled lines — is identical for a Dockerfile ENV instruction and a YAML manifest. Kept the same "reject newlines only" narrowness intentionally, matching the original fix's reasoning (a stricter allowlist would reject the valid, already-tested domain-scoped project id example.com:my-project). Applied to project/region in to_gke, before either value is echoed or reaches any generated file.

Testing

• Standalone reproduction (yaml.safe_load_all against the actual string-templated output) confirms the injection succeeds pre-fix: the parsed Deployment's pod spec has 2 containers, the second fully attacker-controlled.
• New test test_to_gke_rejects_multiline_project_or_region, parametrized over both fields, asserts rejection happens before any subprocess call or file write — not merely before kubectl apply.
• Confirmed via revert-and-retest: reverting the two new validation calls makes the test fail with "DID NOT RAISE ClickException" (the malicious value flows through unrejected to the mocked kubectl apply); restoring them passes.
• Renamed the existing _validate_dockerfile_env_value tests to match — confirms the original to_agent_engine behavior, including the example.com:my-project domain-scoped-id case, is unaffected.
• Full test_cli_deploy.py suite: 121 passed, 2 pre-existing skips, 0 failed, both before and after.