What you would like to be added?

Rename the Grove topology API type from ClusterTopology to ClusterTopologyBinding everywhere it still appears in API types, comments, docs, controller/status wording, tests, and related helper names.

This rename should not be treated as cosmetic only. The updated naming and documentation should make the intended semantics explicit:

• this resource is Grove’s source-of-truth topology hierarchy
• it is also the binding point between that Grove topology model and each scheduler backend’s topology representation
• it is not itself the scheduler backend topology resource

Because this changes the CRD, the issue should also cover the upgrade path. Existing ClusterTopology resources must be handled during upgrade, and the crd-upgrader should be updated to support the migration.

Why is this needed?

The old name ClusterTopology reads like “this CR is the topology object itself,” which is misleading.

In practice, the resource serves two related purposes:

• it defines Grove’s topology hierarchy in Grove terms
• it binds that hierarchy to one or more backend-specific topology resources, which may be Grove-managed or externally managed

That distinction matters for understanding why schedulerTopologyBindings exists, why the controller may create backend topology resources or only check them for drift, and where this API sits relative to scheduler-specific topology objects.

The CRD rename also creates an upgrade concern for existing clusters, so Grove needs a defined migration path either implemented it in the crd-upgrader or clear documentation.

That said, this is expected to be a relatively easy migration because there has not been a Grove release since the change that allowed administrators to create ClusterTopology resources freely. So while migration support is still required, the practical upgrade surface should remain limited.