Fix: select the Vertex backend the user actually chose in adk create

[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):
   No open issue tracks this defect.
2. Or, if no issue exists, describe the change:
   Problem: generateEnvFile picks the backend from the fields that happen to be filled in, not from the backend the user chose. A user who picks Vertex AI and leaves the region empty gets a .env with only GOOGLE_CLOUD_PROJECT, so the runtime takes the Gemini API path and demands an API key. The region is empty whenever GOOGLE_CLOUD_LOCATION and gcloud compute/region are both unset, and adk create demo -y --project p reaches the same state. An --api_key plus --project plus --region invocation also writes both GOOGLE_GENAI_USE_VERTEXAI=0 and =1.

Solution: The project now selects the Vertex backend on its own, and the writer supplies us-central1 when no region is known. The interactive project prompt rejects an empty answer, both Vertex answers are trimmed, and the region prompt is pre-filled with the default. This matches adk-python, where _onboarding.prompt_str loops until the answer is non-empty and prompt_for_google_cloud_region offers us-central1. us-central1 is the default adk-js already uses in AgentEngineSandboxCodeExecutor.

Notes:

• Deliberate side effect: exactly one GOOGLE_GENAI_USE_VERTEXAI line is now emitted. The duplicate =0 and =1 pair is no longer possible.
• Deliberate UX change: the interactive Vertex flow no longer accepts an empty project. The region prompt still accepts an empty answer, because the writer substitutes us-central1 for it. Ctrl+C still exits through the existing isCancel guards.
• Collision check: no open PR on the fork touches dev/src/cli/cli_create.ts. Six open PRs (Fix: pin GOOGLE_CLOUD_* env vars in cli_create_test so the gcloud defaults are actually testable #569, Fix: make cli_create_test hermetic against ambient GOOGLE_CLOUD_* env vars (duplicate of #569) #576, Fix: isolate cli_create tests from ambient Google Cloud env vars (DUPLICATE of #569 — recommend closing) #589, Fix: install the cli_create console spies per test so the CLI unit tests stay silent #666, Fix: let createFolder reject with the original fs.mkdir error so adk create reports the root cause #704, Fix: let removeFolder reject with the original fs.rm error #815) touch dev/test/cli/cli_create_test.ts on unrelated concerns, so this branch adds new it blocks and changes one existing line only: vi.unstubAllEnvs() in the afterEach.

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.

Command:

npx vitest run --project unit:dev dev/test/cli/cli_create_test.ts dev/test/cli/cli_create_env_test.ts

Result: 20 passed. Every line and branch this branch adds to dev/src/cli/cli_create.ts is covered, measured with --coverage.include='dev/src/cli/cli_create.ts'.

Every new test was proven able to fail. Each mutation reverts one hunk of the fix:

Mutation	Tests that failed	Failure message
Restore the old generateEnvFile body	selects the Vertex backend when no region is available	API key must be provided via constructor or GOOGLE_GENAI_API_KEY or GEMINI_API_KEY environment variable.
Restore the old generateEnvFile body	should write exactly one backend selector when an api key and a project are both provided	expected [ '0', '1' ] to deeply equal [ '1' ]
Restore the old generateEnvFile body	should still select Vertex when the region comes back empty, should set Vertex AI env vars when only a project is provided	expected "spy" to be called with arguments: [ StringContaining ".env", …(1) ]
Drop the !options.project guard on the =0 selector	should write exactly one backend selector when an api key and a project are both provided	expected [ '0', '1' ] to deeply equal [ '1' ]
Drop validate from the project prompt	should reject an empty project at the prompt	the project prompt received no validate callback
Drop the seeded initialValue on the region prompt	should seed the region prompt with the default location when gcloud has none	expected "spy" to be called with arguments: [ ObjectContaining{…} ]
Drop both .trim() calls	should trim the Vertex answers	expected "spy" to be called with arguments: [ StringContaining ".env", …(1) ]

One pre-existing test fails on a machine that exports GOOGLE_CLOUD_PROJECT: should handle Vertex AI selection with gcloud defaults reads the ambient value through getGcpProject(). It fails the same way on unmodified main, and open PRs #569, #576 and #589 propose the suite-wide fix. The new tests stub the two variables themselves, so they pass either way.

Manual End-to-End (E2E) Tests:
Please provide instructions on how to manually test your changes, including any necessary setup or configuration.

npm run build
cd $(mktemp -d)
gcloud config unset compute/region
unset GOOGLE_CLOUD_LOCATION GOOGLE_CLOUD_PROJECT
node <adk-js>/dev/dist/esm/cli_entrypoint.js create demo -y --project my-test-project
cat demo/.env

Observed output for that command and for the other three flag shapes:

Flags	Generated .env
-y --project my-test-project	GOOGLE_CLOUD_PROJECT=my-test-project, GOOGLE_CLOUD_LOCATION=us-central1, GOOGLE_GENAI_USE_VERTEXAI=1
-y --api_key test-key --project p --region r	GOOGLE_GENAI_API_KEY=test-key, GOOGLE_CLOUD_PROJECT=p, GOOGLE_CLOUD_LOCATION=r, GOOGLE_GENAI_USE_VERTEXAI=1
-y --api_key test-key	GOOGLE_GENAI_API_KEY=test-key, GOOGLE_GENAI_USE_VERTEXAI=0
-y --region us-west1	GOOGLE_CLOUD_LOCATION=us-west1

Loading the first .env and constructing new Gemini({model: 'gemini-2.5-flash'}) from the built core/dist reports apiBackend = VERTEX_AI.

For the interactive path, run create demo without -y, choose Vertex AI, and check three things: the region prompt is pre-filled with us-central1, an empty project re-asks, and Ctrl+C exits without writing files.

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.