Describe the bug

When an APIResourceSchema has been moved from one APIExport to another, the APIBindings bound to the old APIExport still mark that schema as bound. From what I understand, this may still be expected behavior. However, when this APIResourceSchema is replaced by a newer one (same underlying CRD but different metadata.name) and the new APIExport is updated accordingly, the Workspace effectively ends up with 2 bound CRDs for the same Kind. This makes the apiserver route incoming requests for that Kind to one or the other underlying bound CRD at random, effectively making it look like there are 2 distinct data stores for the same Kind: kubectl get/apply/delete requests will target one or the other at random.

Observed on KCP v0.24.

Steps To Reproduce

1. create APIResourceSchema schema1 that declares a kind Foo
2. create APIExport export1 referencing schema1
3. create APIBinding binding1 referencing export1
4. create a few actual resources of kind Foo
5. remove the reference to schema1 from export1
6. create APIExport export2 referencing schema1
7. create APIBinding binding2 referencing export2
8. at this stage, only export2 references schema1, but it still appears Bound in both binding1 and binding2's Status (note: it seems like the bug is not yet visible here, kubectl get calls still seem to be consistent at that point)
9. create APIResourceSchema schema2 that declares the same underlying CRD as schema1
10. delete schema1
11. update export2 to reference schema2 instead of schema1
12. binding1's Status still indicates that it is bound to schema1 (now deleted) and binding2's Status indicates that it is bound to schema2
13. do kubectl get foo: you will sometimes get the results that were created under schema1's identityHash, and sometimes those under schema2 (an empty list)
14. create a few new Foo resources: they will be created at random between schema1 and schema2's identityHashes, and kubectl get foo will return one list or the other at random

Expected Behaviour

Requests for a given GVK should be consistent.

Additional Context

No response