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>

values.yaml

@@ -302,9 +302,6 @@ schedulerName: ""
 ## @param tolerations Tolerations for the deployment
 tolerations: []
 
-## @param topologySpreadConstraints TopologySpreadConstraints for the deployment
-topologySpreadConstraints: []
-
 ## @section deployment
 deployment:
   ## @param deployment.enabled Enable the deployment of Gitea.
@@ -390,6 +387,13 @@ deployment:
   ## @param deployment.terminationGracePeriodSeconds How long to wait until forcefully kill the pod
   terminationGracePeriodSeconds: 60
 
+  ## @param deployment.topologySpreadConstraints TopologySpreadConstraints for the deployment
+  topologySpreadConstraints: []
+  # - topologyKey: kubernetes.io/hostname
+  #   whenUnsatisfiable: DoNotSchedule
+  #   labelSelector:
+  #     matchLabels:
+  #       app.kubernetes.io/instance: athens-proxy
 
 ## @section Secret
 secrets: