Map region_ids between compute config and WCI scaling group spec

[mani-j9]

What changed?

• Maps region_ids between the compute config API (ComputeConfigScalingGroup and ComputeConfigScalingGroupSummary) and the worker controller's scaling group spec, in all four conversions in service/worker/workerdeployment/compute_util.go: create, update, spec to config and spec to summary.
• Bumps go.temporal.io/api to pick up region_ids (Add region_id to ComputeConfigScalingGroup api#875).

Why?

Scaling groups can list the regions they apply in (region_ids). The worker controller runs where the namespace is active and uses only the groups that list its region, so after a failover it picks the compute for the newly active region. That logic lives in temporal-auto-scaled-workers (temporalio/temporal-auto-scaled-workers#152); the server only passes region_ids through.

Depends on temporalio/temporal-auto-scaled-workers#152, which adds RegionIds to the worker controller's scaling group spec that this maps into. Once it merges, go.temporal.io/auto-scaled-workers gets bumped here; until then this doesn't compile.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)

TestComputeConfigConversions_RegionIds round-trips a group with two AWS regions through all four conversions.

Potential risks

• The OSS server doesn't supply a host region, so the worker controller rejects specs that set region_ids there. Region-scoped groups are only available where the hosting binary supplies a region, such as Temporal Cloud.