Add event recording and status conditions for worker deployments

[thearcticwatch]

What changed: Added Kubernetes events and status conditions

(TemporalConnectionHealthy, RolloutReady) to the worker controller
reconciliation loop.

##Why: Reconciliation failures were only visible in controller logs —
events and conditions let users diagnose issues directly via kubectl.

1. Closes Add events to the TemporalWorkerDeployment CRD when there is a problem #28

2. How was this tested:
   added unit tests and functional tests

3. Any docs updates needed?
   N/A

4. Is this risky? Explain

Making a change to the CRD (adding conditions) opens up the risk that users could upgrade the controller but fail to upgrade their CRD. In this case, it is ok if new features are silently ignored, but we don't want the controller to panic or fail to successfully do the actions that were available in the previous CRD version. I believe that this change is safe even if someone forgets to upgrade their CRD, because when this new controller runs against a v1.2.0 CRD:

• No panic. The controller calls r.Status().Update(ctx, twd) with conditions populated in memory. The API server validates against the CRD schema and prunes unknown fields (standard behavior for structural schemas without x-kubernetes-preserve-unknown-fields). The status write succeeds with a 200 and the conditions are silently dropped before storage.
• Kubernetes Events work fine. Events are written as separate events.k8s.io/v1 resources, completely independent of the TWD CRD schema. All r.Recorder.Eventf(...) calls will succeed normally.
• Conditions simply don't persist. kubectl get twd foo -o yaml will show no conditions field. The controller sets them in memory on every reconcile, tries to write, and the API server drops them. Functionally the controller does the right thing, it just can't communicate the health status via conditions until the CRD is upgraded.

[CLAassistant]

All committers have signed the CLA.

[carlydf]

also make fmt-imports will solve some of your lint errors

[carlydf]

looking good! just did initial review, we should still add a functional test once these comments are addressed.

I found https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#events and https://book.kubebuilder.io/reference/raising-events#creating-events helpful while reviewing.

[carlydf]

really close from my perspective. will push a commit showing what I mean about the stricter string types for EventType and ConditionType.

[carlydf]

Approved, but @Shivs11 if you could take a peek at my refactor of ClientPool which I did so we could emit a separate event type for invalid secret vs failed dial to Temporal server, that would be great!