fix: target Pods only for cc_init_data injection, disable autogen

The autogen Deployment rule causes admission failures when the initdata
ConfigMap hasn't been propagated to the workload namespace yet. By
targeting Pods only (autogen-controllers: none), Deployments are admitted
without ConfigMap resolution. Pods get cc_init_data injected at creation
time when the ConfigMap is available. A rollout restart picks up new
initdata values.

Also removes UPDATE operation — only CREATE is needed since a rollout
restart creates new Pods.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: butler54

charts/all/coco-kyverno-policies/templates/inject-coco-initdata.yaml

@@ -6,14 +6,14 @@ metadata:
     policies.kyverno.io/title: Inject CoCo InitData
     policies.kyverno.io/category: Confidential Computing
     policies.kyverno.io/severity: medium
-    policies.kyverno.io/subject: Pod,Deployment
+    policies.kyverno.io/subject: Pod
     policies.kyverno.io/description: >-
       Injects cc_init_data annotation into pods with a kata runtime class
       by reading from a ConfigMap specified via the coco.io/initdata-configmap
-      annotation. Kyverno autogen extends this to Deployments, StatefulSets,
-      DaemonSets, and Jobs automatically.
+      annotation. Targets Pods only (not Deployments) so that Deployments
+      remain stable and a rollout restart resolves the latest initdata.
     argocd.argoproj.io/sync-wave: "1"
-    pod-policies.kyverno.io/autogen-controllers: Deployment,StatefulSet,DaemonSet,Job
+    pod-policies.kyverno.io/autogen-controllers: none
 spec:
   rules:
     - name: inject-initdata
@@ -24,7 +24,6 @@ spec:
                 - Pod
               operations:
                 - CREATE
-                - UPDATE
       preconditions:
         all:
           - key: "{{ "{{" }}request.object.spec.runtimeClassName || '' {{ "}}" }}"