Upgrade dependencies and make PodHash ignore empty fields

[carlydf]

What was changed

Kubernetes v0.35 added new optional fields to core pod types — notably RestartPolicyRules on Container and HostnameOverride and WorkloadRef on PodSpec. The previous hash implementation used spew to serialize the pod spec, which includes every struct field regardless of whether it is set. Adding new zero-value fields to the struct therefore changed the hash output even when the actual pod spec was unchanged.

The controller now uses json.Marshal to serialize pod specs before hashing. Kubernetes types use omitempty on all optional fields, so new zero-value fields introduced in future API versions are omitted from the JSON output and do not affect the hash.

Added

CHANGELOG.md to track notable changes and serve as a basis for release notes.

---

Upgrade notes for the next release

One-time Build ID rollout. Because the hash algorithm changed, each TemporalWorkerDeployment will be assigned a new build ID on its first reconcile after upgrading the controller. This causes a normal, safe rollout: existing workers continue serving traffic while pods on the new build ID start up, exactly as happens during any image upgrade. No manual intervention is required, and tracking of existing builds and their Temporal routing state is not affected. After this one-time rollout, build IDs will remain stable across future Kubernetes API upgrades.

Why?

We should test against modern servers, and be able to upgrade k8s API anytime without changing build id computation.
This server upgrade was motivated by a desire to test the controller against a new rate limit which was not included in previous servers.

Checklist

1. Closes

2. How was this tested:
   Existing tests. Needed to change expected results for hash tests.

3. Any docs updates needed?
   Updated CHANGELOG.md

[jaypipes]

Is this file being added intentionally? In particular the ## [Unreleased] section header below looks wrong. :)

[carlydf]

yes, I was inspired by https://github.com/kedacore/keda/blob/main/CHANGELOG.md which tracks important changes as they go in, so that come release time it is easier to know what notices to include in the release notes.

We don't have to use this strategy though, I just thought of it because I would like to put a note about the one-time hash function change in our upcoming release notes