Description of problem:

When ClusterInstance is deleted SiteConfig operator deletes generated CRs in reverse wave order. In the default templates this includes BMH at wave 3 and ManagedCluster at wave 2. 

When I delete my ClusterInstance the wave order is being followed correctly but SiteConfig operator does not wait for the resources to be removed before moving to the next wave. This leads to hung deletions where some resources in later waves (deletion order is highest to lowest, so lower wave numbers) are needed by other controllers to clean up BMH (as one example).

Looking at deletes from the audit logs on my hub after removing ClusterInstance:

# wave 3 BMHs deleted
{
    "verb": "delete",
    "requestURI": "/apis/metal3.io/v1alpha1/namespaces/cnfdf02/baremetalhosts/cnfdf02-w3-vworker-6",
    "userAgent": "siteconfig-manager/v0.0.0 (linux/amd64) kubernetes/$Format",
    "timestamp": "2025-06-04T22:01:05.030609569Z"
  }
# last BMH deleted at 2025-06-04T22:01:05.333142858Z

# Wave 2, managedcluster deleted
  {
    "verb": "delete",
    "requestURI": "/apis/cluster.open-cluster-management.io/v1/managedclusters/cnfdf02",
    "userAgent": "siteconfig-manager/v0.0.0 (linux/amd64) kubernetes/$Format",
    "timestamp": "2025-06-04T22:01:05.447598309Z"
  }

Version-Release number of selected component (if applicable):

ACM 2.13

How reproducible:

Steps to Reproduce:

1. Initiate a cluster installation (Assisted install based)
2. Wait until some agents start registering but before the cluster installation gets beyond writing to disk for the first couple control nodes.
3. Delete ClusterInstance CR
4. Note ManagedCluster is removed before BMH CRs are removed
5. ...

Actual results:

Expected results:

Additional info: