### What happened?

I create 2 quotas with different scopes, one is Terminating, and the other is NotTerminating. I create a pod that belongs to NotTerminating, then update the pod's spec.activeDeadlineSeconds with 5, the pod should belong to Terminating. But the quota is not updated.


```shell
Every 2.0s: kubectl get pod,quota -A

NAMESPACE     NAME                          READY   STATUS    RESTARTS   AGE
default       pod/test-pod                  0/1     Pending   0          28s
kube-system   pod/coredns-58cd89f5d-wtpxv   0/1     Pending   0          5m45s

NAMESPACE   NAME                               AGE     REQUEST           LIMIT
default     resourcequota/not-terminating   5m16s   count/pods: 1/1
default     resourcequota/terminating          5m16s   count/pods: 0/1
```

### What did you expect to happen?

Quota scopes can handle the transition case from one scope to another when the target object is updated.

### How can we reproduce it (as minimally and precisely as possible)?

1. Create 2 quotas.
  ```yaml
  apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: terminating
  spec:
    hard:
      count/pods: "1"
    scopes:
    - Terminating
  ---
  apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: not-terminating
  spec:
    hard:
      count/pods: "1"
    scopes:
    - NotTerminating
  ```
2. Create a pod which belongs to not-terminating
  ```yaml
  apiVersion: v1
  kind: Pod
  metadata:
    name: test-pod
  spec:
   
    containers:
    - name: test
      image: ubuntu
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo hello; sleep 10;done"]
  ```
3. Update pod's spec.activeDeadlineSeconds with 5. the pods should belong to terminating
  ```shell
  kubectl patch pod test-pod -p '{"spec":{"activeDeadlineSeconds":5}}'
  ```
4. Get all quotas, you will see the terminating quota is not updated.
  ```shell
  kubectl get quota -A
  ```

### Anything else we need to know?

The root cause is, when the pod is updated, the delta is calculated based on the old object and the new object, it doesn't consider the scope change where the updated object belongs to, so the final delta is not correct.

In this case, the final delta is zero, so the terminating quota is not updated.

Related k/k code: 

https://github.com/kubernetes/kubernetes/blob/5a31a46d4bfe1fcf5962fa9cee23ff3148a094e3/staging/src/k8s.io/apiserver/pkg/admission/plugin/resourcequota/controller.go#L495-L558

When I implement https://github.com/kubernetes/kubernetes/pull/124360, I find this issue.

### Kubernetes version

<details>

```console
(base) (⎈|local-up-cluster:N/A)➜  __testdata git:(kep-3751-quota-2) ✗ kubectl version
Client Version: v1.30.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.31.0-alpha.0.47+5a31a46d4bfe1f-dirty
```

</details>


### Cloud provider

<details>
N/A
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

Quota scopes cannot handle the transition case from one scope to another when the target object is updated.
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : Quota scopes cannot handle the transition case from one scope to another when the target object is updated.
Issue date:

--- start body ---
### What happened?

I create 2 quotas with different scopes, one is Terminating, and the other is NotTerminating. I create a pod that belongs to NotTerminating, then update the pod's spec.activeDeadlineSeconds with 5, the pod should belong to Terminating. But the quota is not updated.


```shell
Every 2.0s: kubectl get pod,quota -A

NAMESPACE     NAME                          READY   STATUS    RESTARTS   AGE
default       pod/test-pod                  0/1     Pending   0          28s
kube-system   pod/coredns-58cd89f5d-wtpxv   0/1     Pending   0          5m45s

NAMESPACE   NAME                               AGE     REQUEST           LIMIT
default     resourcequota/not-terminating   5m16s   count/pods: 1/1
default     resourcequota/terminating          5m16s   count/pods: 0/1
```

### What did you expect to happen?

Quota scopes can handle the transition case from one scope to another when the target object is updated.

### How can we reproduce it (as minimally and precisely as possible)?

1. Create 2 quotas.
  ```yaml
  apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: terminating
  spec:
    hard:
      count/pods: "1"
    scopes:
    - Terminating
  ---
  apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: not-terminating
  spec:
    hard:
      count/pods: "1"
    scopes:
    - NotTerminating
  ```
2. Create a pod which belongs to not-terminating
  ```yaml
  apiVersion: v1
  kind: Pod
  metadata:
    name: test-pod
  spec:
   
    containers:
    - name: test
      image: ubuntu
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo hello; sleep 10;done"]
  ```
3. Update pod's spec.activeDeadlineSeconds with 5. the pods should belong to terminating
  ```shell
  kubectl patch pod test-pod -p '{"spec":{"activeDeadlineSeconds":5}}'
  ```
4. Get all quotas, you will see the terminating quota is not updated.
  ```shell
  kubectl get quota -A
  ```

### Anything else we need to know?

The root cause is, when the pod is updated, the delta is calculated based on the old object and the new object, it doesn't consider the scope change where the updated object belongs to, so the final delta is not correct.

In this case, the final delta is zero, so the terminating quota is not updated.

Related k/k code: 

https://github.com/kubernetes/kubernetes/blob/5a31a46d4bfe1fcf5962fa9cee23ff3148a094e3/staging/src/k8s.io/apiserver/pkg/admission/plugin/resourcequota/controller.go#L495-L558

When I implement https://github.com/kubernetes/kubernetes/pull/124360, I find this issue.

### Kubernetes version

<details>

```console
(base) (⎈|local-up-cluster:N/A)➜  __testdata git:(kep-3751-quota-2) ✗ kubectl version
Client Version: v1.30.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.31.0-alpha.0.47+5a31a46d4bfe1f-dirty
```

</details>


### Cloud provider

<details>
N/A
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

--- end body ---
