COM-132: Add GCP Cloud Run support to worker deployment version command

[gcristea-temporal]

Mirror the AWS Lambda support: four --gcp-cloud-run-* flags on create-version and update-version-compute-config, writing a gcp-cloud-run ComputeConfig provider.

Related issues

What changed?

Add GCP Cloud Run worker pools as a compute provider

Lets an operator point a Worker Deployment Version at a GCP Cloud Run worker pool, mirroring the existing AWS Lambda support 1:1. CLI-only — serializes the four detail keys WCI reads (project, region, worker_pool, service_account)

  temporal worker deployment create-version \                                                        
      --deployment-name YourDeployment --build-id YourBuildID \  
      --gcp-cloud-run-project YourProject \
      --gcp-cloud-run-region us-central1 \
      --gcp-cloud-run-worker-pool YourWorkerPool \
      --gcp-cloud-run-service-account customer-sa@proj.iam.gserviceaccount.com                                                                                         

Changes

• commands.yaml / commands.gen.go: four --gcp-cloud-run-* flags on
  create-version and update-version-compute-config, plus usage examples.
• commands.worker.deployment.go: GCP validate/payload helpers and a
  shared computeProviderConfig selector that enforces AWS/GCP mutual
  exclusivity and dispatches on the trigger flag. Both run methods rewired.
• tests: GCP validation + mutual-exclusivity cases folded into
  TestCreateWorkerDeploymentVersion_Errors; a skipped round-trip test
  mirrors the Lambda one (needs real GCP fixtures).

Checklist

Stability

• Breaking changes are marked with 💥 in the PR title and release notes
• Changes to JSON output (-o json / -o jsonl) are treated as breaking changes

Design

• This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server)
• New commands follow temporal <noun> <verb> structure (e.g. temporal workflow start)
• New flags are named after the API concept, not the implementation mechanism (good: --search-attribute, bad: --index-field)
• New flags don't duplicate an existing flag that serves the same purpose
• New flags do not have short aliases without strong justification
• Experimental features are marked with (Experimental) in commands.yaml

Help text (see style guide at the top of commands.yaml)

• All flags shown in help text and examples are implemented and functional
• Summaries use sentence case and have no trailing period
• Long descriptions end with a period and include at least one example invocation
• Examples use long flags (--namespace, not -n), one flag per line
• Placeholder values use YourXxx form (YourWorkflowId, YourNamespace)

Behavior

• Results go to stdout; errors and warnings go to stderr
• Error messages are lowercase with no trailing punctuation

Tests

• Added functional test(s) (SharedServerSuite)
• Added unit test(s) (func TestXxx) where applicable

Manual tests

Setup

temporal server start-dev --headless
temporal workflow start \
    --type YourWorkflowType \
    --task-queue YourTaskQueue \
    --workflow-id YourWorkflowId

Happy path

$ temporal <command> \
    --flag value
<expected output>

Error case

$ temporal <command> \
    --invalid-combination
Error: <expected error message>
$ echo $?
1

Composition

$ temporal <command-one> ...
$ temporal <command-two> --flag <value-from-above>
<expected output>

[CLAassistant]

All committers have signed the CLA.