The top-level `topologySpreadConstraints` value only ever configured the pod spec of the Gitea Deployment, yet
it lived next to chart-wide settings. This made it hard to tell which values influence the Deployment and which
apply to the chart as a whole. Moving it into the `deployment` dict continues the consolidation already done for
`affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName` and `resources`, so all pod scheduling settings are
now grouped in one predictable place.
A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be particularly harmful here: the constraints would be dropped without any warning and all replicas could end up
scheduled on a single node or zone, defeating the availability guarantees the user configured.
BREAKING CHANGE: `topologySpreadConstraints` no longer exists. Use `deployment.topologySpreadConstraints`
instead. Installations that still set `topologySpreadConstraints` will fail unless `checkDeprecation` is set to
`false`.
Co-authored-by: Copilot <copilot@github.com>
volker.raschekandCopilot
9e12eeccab