feat: add schedulerName, runtimeClassName and priorityClassName to pod specs - #949

This adds three optional, opt-in pod fields (schedulerName, runtimeClassName, priorityClassName) to the server, web and admintools workloads, mirroring the nodeSelector/affinity/tolerations/topologySpreadConstraints knobs already present on these pods.

• server: server-wide value with per-service override, using the same default $.Values.server.<field> $serviceValues.<field> pattern as nodeSelector/affinity/tolerations
• web and admintools: .Values.<component>.<field>

All three default to "", so the rendered output is byte-identical for existing users (no behavior change).

CONTRIBUTING lists "scheduling constraints required by platform policies" as an accepted change. These fields are commonly needed for sandboxed/GPU runtimes (runtimeClassName), custom schedulers, and priority-based preemption.

Validation (run locally):

• helm unittest . -> 152 passed. Added coverage in server_deployment_test.yaml and admintools_deployment_test.yaml, plus a new web_deployment_test.yaml (default renders nothing, set values render, server per-service overrides the server-wide default).
• ct lint --check-version-increment=false -> all charts linted successfully across the mysql / postgres-es / postgres ci value files.
• helm template default render diff vs main is empty (byte-identical); with the fields set they render on every enabled workload.

I did not run the kind ct install scenario since the ci/*-values.yaml files do not set these fields and the default render is unchanged, so it would exercise nothing new. Happy to add a ci scenario if you prefer.