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>

unittests/helm/deployment/deprecations.yaml

@@ -60,6 +60,12 @@ tests:
     asserts:
       - failedTemplate:
           errorMessage: "`resources` does no longer exist. Please refer to the changelog and configure `deployment.gitea.resources` instead."
+  - it: fails when the removed `schedulerName` value is set
+    set:
+      schedulerName: stork
+    asserts:
+      - failedTemplate:
+          errorMessage: "`schedulerName` does no longer exist. Please refer to the changelog and configure `deployment.schedulerName` instead."
   - it: fails when the removed `tolerations` value is set
     set:
       tolerations:
@@ -94,6 +100,7 @@ tests:
       resources:
         limits:
           cpu: 100m
+      schedulerName: stork
       tolerations:
         - key: database/type
           operator: Equal