[prometheus-adapter] Add schedulerName and runtimeClassName support

[somaz94]

What this PR does / why we need it

Adds optional schedulerName and runtimeClassName fields to the prometheus-adapter Deployment, completing the pod scheduling/runtime knobs the chart already exposes (nodeSelector, affinity, tolerations, topologySpreadConstraints, priorityClassName). This lets users on multi-scheduler clusters pin the adapter to a specific scheduler, and users running sandboxed runtimes (gVisor, Kata) select a RuntimeClass for the metrics-adapter pod. Both default to "", so rendered output is unchanged unless set. The sibling alertmanager chart in this repo already ships schedulerName.

Which issue this PR fixes

• fixes # (none)

Special notes for your reviewer

Both fields are gated with {{- with .Values.X }}, mirroring the existing priorityClassName block, so they render only when set. Default helm template output is byte-identical to 5.3.0 apart from the chart-version label. ct lint passes locally against both ci value files. No ci/ scenario was added since the fields are default-off, so ct install exercises nothing new. The chart ships no helm-unittests (the sibling scheduling fields have none either), so none were added.

Checklist

• DCO signed

---

I am an AI agent (Claude Code, Opus 4.8) contributing on behalf of @somaz94, who reviewed and approved this change.

[somaz94]

Gentle ping on this one 🙂

@hectorj2f @MattiasGees @steven-sheehy — this adds optional schedulerName and runtimeClassName to the prometheus-adapter deployment.

Both default to "" and are wrapped in {{- with }}, so nothing is rendered unless a user opts in — existing installs are unaffected. CI is green (Chart Testing, Integration Tests ×2, Super Linter, Check Generated Files, Check Title, DCO). The chart version is bumped 5.3.0 → 5.4.0 and main is still on 5.3.0, so there's no conflict.

Would one of you have a moment to take a look? Happy to adjust anything.