CNTRLPLANE-2914 Add controlPlaneVersion status field to HostedCluster and HostedControlPlane

# Add controlPlaneVersion status field to HostedCluster and HostedControlPlane **[CNTRLPLANE-2914](https://issues.redhat.com/browse/CNTRLPLANE-2914)** | [Jira](https://issues.redhat.com/browse/CNTRLPLANE-2914) | Epic: [CNTRLPLANE-402](https://issues.redhat.com/browse/CNTRLPLANE-402) As a service provider (ROSA/ARO), I want a dedicated controlPlaneVersion field on HostedClusterStatus and HostedControlPlaneStatus that tracks management-side control plane component version history independently from CVO, so that I can detect completed control plane upgrades, verify CVE patches, and compute NodePool version skew without waiting for data-plane rollout. ## Background Today there is no mechanism to report control plane version status independently from CVO. Control plane upgrades remain coupled to the data plane — HostedClusterStatus.Version reflects CVO-reported ClusterVersion, which only reaches Completed when data-plane components finish rolling out. This story introduces a new `controlPlaneVersion` status field that reports exclusively on management-side components represented by ControlPlaneComponent resources, as specified in the [enhancement](https://github.com/openshift/enhancements/pull/1950). The new field coexists with the existing `version` field (CVO-reported, data plane). After this change: - `controlPlaneVersion` = management-side components done (reaches Completed first) - `version` = full cluster done including data plane (existing behavior, unchanged) ## Deliverables - Add `ControlPlaneVersionStatus` and `ControlPlaneUpdateHistory` API types to the HyperShift API (`api/hypershift/v1beta1/`) - Add `controlPlaneVersion` field to `HostedClusterStatus` and `HostedControlPlaneStatus` - Implement reconciliation logic in the HostedControlPlane controller (CPO) to track management-side component versions via `ControlPlaneComponent` resources - Bubble up `controlPlaneVersion` from HCP status to HC status in the HyperShift operator, following the existing HCP-to-HC status propagation pattern - Implement history pruning using CVO's weighted ranking algorithm (cap at 100 entries) - Regenerate CRDs, vendored types, and API docs via `make update` - In e2e, add `WaitForControlPlaneRollout` (checks `controlPlaneVersion`) and rename `WaitForImageRollout` to `WaitForDataPlaneRollout` (checks `version`), replacing `WaitForControlPlaneComponentRollout` - Version-gate all new `controlPlaneVersion` e2e assertions since the same suite runs against older HC versions that don't have this field ## Acceptance Criteria - Implementation conforms with the [enhancement](https://github.com/openshift/enhancements/pull/1950) - Test that `controlPlaneVersion.history[0].State` transitions to `Completed` when all `ControlPlaneComponent` resources report the target version with `RolloutComplete=True` - Test that `controlPlaneVersion` reaches `Completed` before or at the same time as `version` (never after) - Test that a new `Partial` history entry is prepended when the desired release changes (both version string and image are compared, using the HCP spec release image as reference) - Test that an image-only change (same semver, different image digest) is detected as a new version transition and prepends a new `Partial` entry - Test that version history correctly tracks z-stream and y-stream upgrades with accurate `startedTime` and `completionTime` timestamps - Test that a `ControlPlaneComponent` added mid-upgrade blocks completion until it reaches the desired version - Test that when `controlPlaneVersion` is first populated on an existing cluster, it initializes with a `Partial` entry that transitions to `Completed` on the next successful reconciliation if all components are already at the desired version - Test that history is capped at 100 entries with pruning that preserves: the initial (oldest) entry, the most recent entries, completed entries at minor version boundaries, and the most recent completed entry - Verify that `controlPlaneVersion.desired` reflects `HostedControlPlane.Spec.ControlPlaneReleaseImage` when set, and `Spec.ReleaseImage` otherwise - Verify that `observedGeneration` is only updated when the reconciliation successfully processes the generation - Verify that error scenarios maintain a `Partial` history entry for the desired version (consistent with CVO error handling) - Verify that consumers (HC controller) gracefully handle a nil `controlPlaneVersion` on HCP status during version skew scenarios (older CPO) - Verify that existing `HostedClusterStatus.Version` and `HostedControlPlaneStatus.VersionStatus` fields continue to be populated and function as before - E2E: In `TestUpgradeControlPlane`, replace `WaitForControlPlaneComponentRollout` with `WaitForControlPlaneRollout` (checks `HC.Status.ControlPlaneVersion`), and rename `WaitForImageRollout` to `WaitForDataPlaneRollout` (checks `HC.Status.Version`). Both use the same pattern. - E2E: Update `ValidateHostedClusterConditions` (the central before/after-each-test validator) to also check `controlPlaneVersion` state. For steady-state clusters it should be `Completed`, and for zero-worker-node clusters it can be `Completed` even when `version` is `Partial` - E2E: All new `controlPlaneVersion` assertions must be version-gated (e.g. `AtLeast(t, Version422)`) since the same e2e suite runs against older HC versions that don't have this field ## API Types ```go type ControlPlaneVersionStatus struct { Desired configv1.Release `json:"desired"` History []ControlPlaneUpdateHistory `json:"history,omitempty"` ObservedGeneration int64 `json:"observedGeneration"` } type ControlPlaneUpdateHistory struct { State configv1.UpdateState `json:"state"` StartedTime metav1.Time `json:"startedTime"` CompletionTime *metav1.Time `json:"completionTime,omitempty"` Version string `json:"version"` Image string `json:"image"` } ``` ## References - Enhancement PR: [openshift/enhancements#1950](https://github.com/openshift/enhancements/pull/1950) - Prior art (ControlPlaneUpToDate condition): [hypershift#6300](https://github.com/openshift/hypershift/pull/6300)