[Helm Chart 1.18.0][OpenShift] rbac.createSCCRoleBinding anyuid RoleBinding missing api-server & dag-processor ServiceAccounts -> pods rejected by SCC (restricted-v2), release fails/times out

### Official Helm Chart version

1.18.0 (latest released)

### Apache Airflow version

3.1.5

### Kubernetes Version

Server Version: v1.31.5

### Helm Chart configuration

# Official Airflow Helm chart
chartVersion: 1.18.0

rbac:
create: true
createSCCRoleBinding: true

Components enabled include:
- api-server (Deployment + ServiceAccount)
- dag-processor (Deployment + ServiceAccount)
OpenShift namespace uses default SCC admission (restricted-v2).
No custom SCCs were assigned manually.

### Docker Image customizations

We use a custom Airflow docker image based on Apache Airflow.
However, the issue is not specific to our code: it is an OpenShift SCC admission failure caused by the SCC RoleBinding created by the chart missing component ServiceAccounts (api-server, dag-processor). Without the anyuid SCC binding applied to those SAs, pods are evaluated against restricted-v2 and rejected due to fixed UIDs (e.g. 50000 for Airflow, 65533 for git-sync) and fsGroup=0.

### What happened

Installing the Helm chart on OpenShift fails / times out because some pods cannot be created due to SCC admission errors.

The chart creates a RoleBinding:
- kind: RoleBinding
- roleRef: ClusterRole `system:openshift:scc:anyuid`

…but the subjects list does NOT include ServiceAccounts for:
- `epis-orchestration-airflow-api-server`
- `epis-orchestration-airflow-dag-processor`

As a result, ReplicaSets for api-server and dag-processor fail to create pods with errors like:
- `provider "anyuid": Forbidden: not usable by user or serviceaccount`
- `restricted-v2: runAsUser 50000 must be in the ranges: []`
- `restricted-v2: fsGroup 0 is not an allowed group`
- for dag-processor also: `runAsUser 65533` (git-sync) rejected by restricted-v2

This blocks the installation and results in:
`failed post-install ... timed out waiting for the condition`.

### What you think should happen instead

When `rbac.createSCCRoleBinding=true`, the chart should include *all enabled component ServiceAccounts* in the OpenShift SCC RoleBinding to `system:openshift:scc:anyuid`.

At minimum (when those components are enabled / SAs exist), the RoleBinding subjects should include:
- `ServiceAccount: epis-orchestration-airflow-api-server`
- `ServiceAccount: epis-orchestration-airflow-dag-processor`

This would allow pods to be admitted on OpenShift without manual SCC/RBAC workarounds.

### How to reproduce

1. Use an OpenShift cluster (tested on OpenShift 4.18.1) with default SCC admission (restricted-v2) in the target namespace.
2. Install Airflow Helm chart `1.18.0` with:
- `rbac.create=true`
- `rbac.createSCCRoleBinding=true`
- with api-server and dag-processor enabled (Deployments & ServiceAccounts are created).
3. Observe that the chart-created RoleBinding `epis-orchestration-airflow-scc-rolebinding` contains subjects:
- webserver, worker, scheduler, triggerer, migrate-database-job, create-user-job
but is missing:
- api-server, dag-processor
4. ReplicaSets for api-server and dag-processor fail pod creation due to SCC admission errors.
5. Workaround: manually create an additional RoleBinding to `system:openshift:scc:anyuid` for the missing ServiceAccounts; then pods can be created.

### Anything else

_No response_

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

### Code of Conduct

- [x] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

Locate the Helm template that renders the SCC RoleBinding controlled by rbac.createSCCRoleBinding, then inspect its subjects alongside the enabled api-server and dag-processor ServiceAccounts. Render or install the chart with both components enabled on OpenShift and verify that the binding includes every enabled component ServiceAccount and the pods pass SCC admission.

Written by the indexing model from the issue text.