[BUG] ContainerRecreateRequest stuck in Pending when recreating different containers in the same Pod continuously #2474

What happened:
When using ContainerRecreateRequest (CRR) to restart a specific container in a Pod, the first CRR succeeds. After deleting the successful CRR, if I immediately create a new CRR to restart another container in the exact same Pod, the second CRR gets stuck in the Pending state indefinitely.

This process is executed programmatically via code. Interestingly, if I add a delay of a few seconds between deleting the first CRR and creating the second one, the issue does not occur, and the second CRR is processed normally.

What you expected to happen:
The Kruise controller should be able to process the second ContainerRecreateRequest normally and recreate the second container without getting stuck in the Pending state, even if the second CRR is created immediately after the deletion of the first one.

How to reproduce it (as minimally and precisely as possible):

1. Deploy a Pod with at least two containers (e.g., container-a and container-b).
2. Create a ContainerRecreateRequest (CRR-1) to recreate container-a.
3. Wait for CRR-1 to complete successfully.
4. Delete CRR-1.
5. Immediately (via script/code, without sleep) create a new ContainerRecreateRequest (CRR-2) targeting container-b in the same Pod.
6. Observe that CRR-2 remains in the Pending state and does not progress.

Anything else we need to know?:
This seems to be related to the informer cache sync delay or state conflict. Since adding a few seconds of sleep between the operations resolves the issue, it is highly likely that when the second CRR is created, the Kruise controller or daemon is reading a stale Pod state from the cache (possibly thinking the Pod is still undergoing the previous recreation process), which blocks the processing of the new CRR.

Environment:

• Kruise version: master branch (built on May 25, 2026)
• Kubernetes version (use kubectl version): v1.30.14
• Install details (e.g. helm install args):
  kruise-manager startup args:

  args: 
    - '--enable-leader-election' 
    - '--metrics-addr=:8080' 
    - '--health-probe-addr=:8000' 
    - '--logtostderr=true' 
    - '--leader-election-namespace=kruise-system' 
    - '--v=4' 
    - >- 
      --feature-gates=ResourcesDeletionProtection=true,CloneSetShortHash=true,InPlaceUpdateEnvFromMetadata=true,PodWebhook=true,PreDownloadImageForInPlaceUpdate=false,PodUnavailableBudgetDeleteGate=false,WorkloadSpread=true,StatefulSetAutoDeletePVC=false,PodProbeMarkerGate=false 
    - '--sync-period=1h' 
    - '--cloneset-workers=10' 
    - '--statefulset-workers=10'