Support separate connection handling for controller and worker pods

The ask here is to be able to configure the Temporal connection credentials separately for the temporal-worker-controller Pod from the Pods that contain Temporal workers.

As of Sept 9, 2026 (v1.10.1 release of TWC), the temporal-worker-controller Pod connects to a Temporal API server using the credentials described in the Connection or ClusterConnection object pointed at by the WorkerDeployment.spec.workerOptions.connectionRef field.

These same connection credentials and host/endpoint information is injected into the Pod definition for Temporal workers that belong to a Kubernetes Deployment associated with a WorkerDeploymentVersion (build ID) managed by temporal-worker-controller for that WorkerDeployment.

The user should be able to use different credentials for the controller Pod than the worker Pods. The worker Pods do not need the same level of access to the Temporal server as the controller Pod -- for example, the controller Pod needs to be able to call control plane APIs like SetWorkerDeploymentRampingVersion and DeleteWorkerDeploymentVersion whereas the worker Pod connects to the Temporal server using the sdk's worker.Start APIs.

We should add the ability to configure the controller Pod's Temporal connection credentials entirely separately from the worker Pods. One idea is to have a WorkerDeployment.spec.controllerConnectionRef field that would allow the controller's connection to be different from the WorkerDeployment.spec.workerOptions.connectionRef.

Start by tracing WorkerDeployment.spec.workerOptions.connectionRef into the temporal-worker-controller Pod and the worker Pod definition, then review the WorkerDeployment.spec fields and the worker.Start connection usage described in the issue. Done means the controller Pod can use separate credentials and host information from worker Pods while existing worker connection behavior remains supported; tests should cover both references.