feat(deployment)!: move topologySpreadConstraints to deployment.topologySpreadConstraints

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>

templates/gitea/deprecation.yaml

@@ -69,4 +69,9 @@
   {{- if .Values.resources -}}
     {{- fail "`resources` does no longer exist. Please refer to the changelog and configure `deployment.gitea.resources` instead." -}}
   {{- end -}}
+
+  {{/* TOPOLOGY SPREAD CONSTRAINTS */}}
+  {{- if .Values.topologySpreadConstraints -}}
+    {{- fail "`topologySpreadConstraints` does no longer exist. Please refer to the changelog and configure `deployment.topologySpreadConstraints` instead." -}}
+  {{- end -}}
 {{- end -}}