[EKS] [request]: upgrade path to SELinuxMount feature gate enabled

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
Improve ability to prepare for the `SELinuxMount` feature gate being enabled.
Possible solutions:
* ability to enable selinux-warning-controller in the kube-controller-manager on EKS 1.36 clusters, perhaps via a new [control plane configuration parameter](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-configuration-getting-started.html#_supported_values)
* new upgrade insight that checks for selinux volume conflicts/context mismatches on EKS 1.36 clusters

**Which service(s) is this request for?**
EKS

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
On SELinux-enforcing systems, enabling the SELinuxMount feature gate introduces a potentially breaking change.

In upstream Kubernetes 1.36, the `SELinuxMount` feature gate is off by default.
It is also not enabled in EKS 1.36. The breaking change will be activated in some future version of EKS.

The [suggested upgrade path](https://kubernetes.io/blog/2026/04/22/breaking-changes-in-selinux-volume-labeling/#suggested-upgrade-path) in upstream K8S documentation suggests enabling the new selinux-warning-controller to report volume conflicts so they can be addressed prior to upgrading to a Kubernetes version with SELinuxMount feature flag enabled.

The selinux-warning-controller is not enabled by default in upstream Kubernetes 1.36, nor is it enabled in EKS 1.36, and there is currently no option to enable it in EKS.

The recent upstream release announcement for 1.37 [confirms the SELinuxMount feature flag will be enabled by default](https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/#selinuxmount-and-selinuxchangepolicy), so presumably the same will be true in EKS 1.37.

EKS users currently cannot follow the suggested upgrade path to prepare for the SELinuxMount changes.

**Are you currently working around this issue?**
As a backup plan to official support, we are considering:
* analyzing the specs of all the workloads on our cluster (a wheel we should not have to reinvent) to identify problematic usages
* using a mutation policy to opt out of the volume labeling changes on every pod by setting `spec.securityContext.seLinuxChangePolicy: Recursive` (forgoing potential performance improvements from the change to volume labeling strategy)

**Additional context**
[EKS 1.36 version notes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-standard.html) state:
> Action required: Customers running SELinux-enforcing systems should audit clusters and ensure the seLinuxChangePolicy field and SELinux volume labels are correctly set on Pods before upgrading.

This gives the false impression that the breaking change activates upon upgrade to EKS 1.36. In reality, no action is required until preparing to upgrade to whatever version of EKS enables the `SELinuxMount` feature flag.
This confusion is compounded by lack of clear documentation regarding EKS policy re: feature gates and controller flags ([as discussed here](https://github.com/aws/containers-roadmap/issues/512#issuecomment-2566407932)).

To verify the actual enabled feature gates and controller flags, I had to upgrade a cluster to 1.36 and confirm via control plane logs.

**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

Start with the EKS 1.36 version notes, the linked upstream suggested upgrade path, and the control plane configuration documentation. Determine whether EKS can expose the selinux-warning-controller or provide an upgrade insight before SELinuxMount is enabled; done means users can identify and address conflicts before the breaking change.

Written by the indexing model from the issue text.