Repository: kubernetes
Issue: Error when patching Scale subresource of CRD (silent error when merge patching)
Labels: kind/bug,sig/api-machinery,triage/accepted

### What happened?

Created a CRD and tried changing its `/scale` subresource by patching the subresource, rather than through the top-level resource. 

When merge patching /scale, there is a silent failure with a scary log on the apiserver backend, but the object is updated with incorrect managed fields.

When apply patching /scale, there is an error returned to the client `failed to create typed patch object (/; autoscaling/v1, Kind=Scale): no corresponding type for autoscaling/v1, Kind=Scale`

### What did you expect to happen?

Successful patch, and new managed fields entry for "scaler" field manager which owns replicas field.

### How can we reproduce it (as minimally and precisely as possible)?

Apply CRD with `kubectl apply --server-side`:
```yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: noxus.mygroup.example.com
spec:
  group: mygroup.example.com
  names:
    plural: noxus
    singular: nonenglishnoxu
    shortNames:
      - foo
      - bar
      - abc
      - def
    kind: WishIHadChosenNoxu
    listKind: NoxuItemList
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          x-kubernetes-preserve-unknown-fields: true
      subresources:
        status: {}
        scale:
          specReplicasPath: .spec.replicas
          statusReplicasPath: .status.replicas
          labelSelectorPath: .status.anotherLabelSelector
  conversion:
    strategy: None
```

Apply Instance with `kubectl apply --server-side`:
```yaml
apiVersion: mygroup.example.com/v1
kind: WishIHadChosenNoxu
metadata:
  name: foo
  namespace: not-the-default
spec:
  num: 10
  replicas: 3
```

Use merge patch to change Scale subresource spec.replicas:
```
❯ kubectl patch foo foo --subresource='scale' --type='merge' -p '{"spec":{"replicas":3}}' --namespace="not-the-default" --field-manager="scaler"
scale.autoscaling/foo patched
```

See error logged by server:
```
E0306 12:51:16.136193   31856 fieldmanager.go:152] "[SHOULD NOT HAPPEN] failed to update managedFields" err="failed to convert new object (not-the-default/foo; autoscaling/v1, Kind=Scale) to smd typed: no corresponding type for autoscaling/v1, Kind=Scale" versionKind="autoscaling/v1, Kind=Scale" namespace="not-the-default" name="foo"
```

Also observe that despite the field being updated, the managed fields entry for replicas has been removed:
```
❯ kubectl get foo foo --namespace=not-the-default -o yaml --show-managed-fields
apiVersion: mygroup.example.com/v1
kind: WishIHadChosenNoxu
metadata:
  creationTimestamp: "2023-03-06T20:51:08Z"
  generation: 2
  managedFields:
  - apiVersion: mygroup.example.com/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        .: {}
        f:num: {}
    manager: kubectl
    operation: Apply
    time: "2023-03-06T20:51:08Z"
  name: foo
  namespace: not-the-default
  resourceVersion: "420"
  uid: 59014404-4fcb-4b12-a7f1-513c875de7f2
spec:
  num: 10
  replicas: 5
```

If I change the replicas without going through the sub resource, my managed fields are updated as expected:
```
❯ kubectl patch foo foo --type='merge' -p '{"spec":{"replicas":6}}' --namespace="not-the-default" --field-manager="scaler"
wishihadchosennoxu.mygroup.example.com/foo patched

~/Desktop [⌛ 178ms]
❯ kubectl get foo foo --namespace=not-the-default -o yaml --show-managed-fields
apiVersion: mygroup.example.com/v1
kind: WishIHadChosenNoxu
metadata:
  creationTimestamp: "2023-03-06T20:51:08Z"
  generation: 3
  managedFields:
  - apiVersion: mygroup.example.com/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        .: {}
        f:num: {}
    manager: kubectl
    operation: Apply
    time: "2023-03-06T20:51:08Z"
  - apiVersion: mygroup.example.com/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        f:replicas: {}
    manager: scaler
    operation: Update
    time: "2023-03-06T20:56:21Z"
  name: foo
  namespace: not-the-default
  resourceVersion: "483"
  uid: 59014404-4fcb-4b12-a7f1-513c875de7f2
spec:
  num: 10
  replicas: 6
```

Using a controller to update the status via `ApplyPatchType` also yields the same behavior except that rather than failing silently as `MergePatchType` does, there is an error returned to the client:

`failed to create typed patch object (/; autoscaling/v1, Kind=Scale): no corresponding type for autoscaling/v1, Kind=Scale`

### Anything else we need to know?

There is an integration test for this case but since it does not supply any openapi definitions, it runs the test apiserver under a configuration that causes SSA to use deduced type converter for all types. Under the test, `Scale` models are never looked up. Since kube-apiserver supplies open api definitions, the lookup is enforced, and fails. 

https://github.com/kubernetes/kubernetes/blob/964529b227331f1f7970aade54123413e795a267/staging/src/k8s.io/apiextensions-apiserver/test/integration/subresources_test.go#L386

I believe lookup fails because `Scale` types are injected by builder into CRD openapi specs without their GVKs. They have no GVK due to definition namer for injected CRD types being initialized with empty scheme. The scheme is used to add the extension with GVK to the definition:

https://github.com/kubernetes/kubernetes/blob/68eea2468c58b7bd24ec871686795983b7a41ffd/staging/src/k8s.io/apiextensions-apiserver/pkg/controller/openapi/builder/builder.go#L471

/cc @apelisse 
/sig api-machinery
/assign

### Kubernetes version

running local cluster based off of master