Fix: pin connection on deprecated versions

[niyomukiza-mechack]

What was changed

In internal/planner/planner.go there's a getUpdateDeployments function that gets called during the planning process and looks at the observed state and returns a list of of existing Deployments that need their pod/connection updated.
Currently there's a loop that propagates connectionRef changes to draining and drained versions.
I deleted that loop so that only target and current versions now follow connectionRef changes. Deprecated versions(draining and drained) keep the connection baked into their Deployment at creation time.

During end to end testing I ran into a Kubernetes validation error(volumeMounts[0].name: Not found: "/etc/temporal/tls") from my previous pr(#516 (comment)), ensureTLSVolumeMount was setting Name instead of MountPath so I addressed that here.

Why?

Context: #493
When switching ConnectionRef switching connectionRef on their WorkerDeployments. The controller re-pointed all versions(current,draining and drained) at the new connection. Draining versions had working credentials and were serving open pinned workflows so they should have been left untouched.

Checklist

1. Closes

2. How was this tested:

Unit tests
Local end 2 end (Kind cluster + Temporal Cloud)
I reproduced the bug and verified the fix with a 3 version rainbow deployment (v1 DRAINING, v2 DRAINING, v3 CURRENT) connected to ns-nm-twc-01.temporal-dev namespace over mTLS.

Before the fix: I changed mutualTLSSecretRef from temporal-cloud-mtls to temporal-cloud-mtls-2. All three versions updated:

After the fix: I made the same connection change. Only v3 (current version) updated; v1 and v2 (draining) stayed pinned

Auth switch of mTLS to API key was not testable in local staging due to environment constraint. I got a certificate signed by unknown authority and similar errors I mentioned in #493

3. Any docs updates needed?

[jaypipes]

👍 just fixes a typo from a previous PR. all good.