Versions are not correctly reflected for clusterctl

[MaxRink]

What steps did you take and what happened:
If i have an existing cluster bootstrapped by clusterctl and i then migrate to the cluster-api-operator the version statuis never gets correctly reflected in clusterctl

clusterctl upgrade plan

Checking new release availability...

Latest release available for the v1beta1 API Version of Cluster API (contract):

NAME                     NAMESPACE                           TYPE                     CURRENT VERSION   NEXT VERSION
bootstrap-kubeadm        capi-kubeadm-bootstrap-system       BootstrapProvider        v1.7.4            v1.8.1
control-plane-kubeadm    capi-kubeadm-control-plane-system   ControlPlaneProvider     v1.7.4            v1.8.1
cluster-api              capi-system                         CoreProvider             v1.7.4            v1.8.1
ipam-in-cluster          capi-ipam-in-cluster-system         IPAMProvider             v0.1.0            Already up to date
ipam-infoblox            capi-ipam-infoblox-system           IPAMProvider             v0.1.0-alpha.7    Already up to date
infrastructure-metal3    capm3-system                        InfrastructureProvider   v1.7.1            Already up to date
infrastructure-vsphere   capv-system                         InfrastructureProvider   v1.10.2           v1.11.0

You can now apply the upgrade by executing the following command:

clusterctl upgrade apply --contract v1beta1

❯ k get infrastructureproviders.operator.cluster.x-k8s.io,ipamproviders.operator.cluster.x-k8s.io,coreproviders.operator.cluster.x-k8s.io,bootstrapproviders.operator.cluster.x-k8s.io,controlplaneproviders.operator.cluster.x-k8s.io -A
NAMESPACE      NAME                                                       INSTALLEDVERSION   READY
capm3-system   infrastructureprovider.operator.cluster.x-k8s.io/metal3    v1.7.1             True
capv-system    infrastructureprovider.operator.cluster.x-k8s.io/vsphere   v1.11.0            True

NAMESPACE                   NAME                                              INSTALLEDVERSION   READY
capi-ipam-infoblox-system   ipamprovider.operator.cluster.x-k8s.io/infoblox   v0.1.0-alpha.7     True

NAMESPACE     NAME                                                 INSTALLEDVERSION   READY
capi-system   coreprovider.operator.cluster.x-k8s.io/cluster-api   v1.8.1             True

NAMESPACE                       NAME                                                  INSTALLEDVERSION   READY
capi-kubeadm-bootstrap-system   bootstrapprovider.operator.cluster.x-k8s.io/kubeadm   v1.8.1             True

NAMESPACE                           NAME                                                     INSTALLEDVERSION   READY
capi-kubeadm-control-plane-system   controlplaneprovider.operator.cluster.x-k8s.io/kubeadm   v1.8.1             True

What did you expect to happen:
Cluster-api-operator keeps the versions in sync so that clusterctl still shows the installed versions correcntly

Anything else you would like to add:

Environment:

• Cluster-api-operator version: 0.12.0
• Cluster-api version: 1.8.1
• Minikube/KIND version:
• Kubernetes version: (use kubectl version): 1.30
• OS (e.g. from /etc/os-release):

/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api-operator/labels?q=area for the list of labels]

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI Operator contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten