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

The top-level `schedulerName` value only ever configured the pod spec of the Gitea Deployment, but was declared
next to chart-wide settings. Moving it into the `deployment` dict completes the consolidation already done for
`affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName`, `resources`, `tolerations` and
`topologySpreadConstraints`, so every pod scheduling setting now lives in one predictable place.

A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be hard to debug: the pod would fall back to the `default-scheduler` without any warning, bypassing the custom
scheduler the user relies on for placement decisions such as storage locality.

BREAKING CHANGE: `schedulerName` no longer exists. Use `deployment.schedulerName` instead. Installations that
still set `schedulerName` will fail unless `checkDeprecation` is set to `false`.

Co-authored-by: Copilot <copilot@github.com>

values.yaml

@@ -293,12 +293,6 @@ gatewayAPI:
       #   maxSize: 100m
 
 
-## Use an alternate scheduler, e.g. "stork".
-## ref: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/
-##
-## @param schedulerName Use an alternate scheduler, e.g. "stork"
-schedulerName: ""
-
 ## @section deployment
 deployment:
   ## @param deployment.enabled Enable the deployment of Gitea.
@@ -381,6 +375,9 @@ deployment:
     #   cpu: 100m
     #   memory: 128Mi
 
+  ## @param deployment.schedulerName Use an alternate scheduler, e.g. "stork"
+  schedulerName: ""
+
   ## @param deployment.terminationGracePeriodSeconds How long to wait until forcefully kill the pod
   terminationGracePeriodSeconds: 60