Check PodSecurityViolation behavior on 4.11 to 4.12 updates

4.12.0-ec.3 included cluster-kube-apiserver-operator#1369 tightening pod/container security admission from "warn" to "reject" (I think?). We should test the UX by:

1. Launching a 4.11 cluster.
2. Installing a violating workload.
3. Confirm that PodSecurityViolation starts firing.
4. Request an update to 4.12.0-ec.3.
5. See how the workload handles the end-of-update rolling machine-config reboots.

If the workload continues to have non-fatal admission warnings, that suggests that I'm misunderstanding cluster-kube-apiserver-operator#1369.

If the workload fails to restart now that the warnings are fatal, we might want a new admin-ack on 4.11.z, similar to the Kube-API-removal OCPBUGS-1251, for "If your cluster, or any idle workloads or tools use...", so that admins are not surprised if non-compliant workloads break post-update.