Introduce v1beta2 conditions for HetznerBareMetalHost

[abdullah599]

Summary

Add v1beta2 conditions to HetznerBareMetalHost while keeping the existing v1beta1 conditions unchanged.

What would you like to add

HetznerBareMetalHost is a primary infrastructure object that represents a real Hetzner dedicated (Robot) server and drives its provisioning state machine (rescue, image install, OS running, deprovisioning, deleting).

Today the host lifecycle is surfaced through v1beta1 conditions such as:

Condition	Purpose
CredentialsAvailable	SSH credentials in the referenced secret are valid
RobotCredentialsAvailable	Hetzner Robot API credentials are valid and reachable
RootDeviceHintsValidated	The configured root device hints match the discovered hardware
ProvisionSucceeded	The host has reached OperatingSystemRunning (provisioning finished)
HetznerAPIReachable	The controller is not blocked by Robot API rate limiting

These conditions are still needed and must keep their current behavior. At the same time, the CAPI v1beta2 transition requires HetznerBareMetalHost to expose v1beta2 conditions in parallel.

Deletion also needs to be visible more clearly. Today deletion is signalled through Spec.Status.ProvisioningState = StateDeleting and finalizer removal in actionDeleting, but no dedicated condition is set. We want a v1beta2 Deleting condition for HetznerBareMetalHost, since this resource has a finalizer and a delete reconciliation path.

Note

HetznerBareMetalHostStatus is an empty struct today: the controller-managed status (including Conditions) lives under Spec.Status (ControllerGeneratedStatus). The placement of status.v1beta2.conditions will follow the same approach used for the existing v1beta1 conditions on this type so that no schema reshuffle is required for this phase.

The Solution

Follow the same structure used for HCloudMachine and HetznerBareMetalMachine:

• Add v1beta2.conditions to HetznerBareMetalHost alongside the existing v1beta1 conditions.
• Keep writing the existing v1beta1 conditions exactly as today.
• Add direct v1beta2conditions.Set(...) calls in the same controller and host-service code paths that already set the v1beta1 conditions.
• Add a controller local patch step for HetznerBareMetalHost that computes:
  • the legacy v1beta1 summary
  • the v1beta2 Ready summary
  • the owned v1beta2 condition set for patching
• Rename HetznerAPIReachable to RobotRateLimitExceeded in v1beta2 with negative polarity (True = rate limited). Set to False on every successful reconcile (happy path setter).
• Add a dedicated v1beta2 Deleting condition (negative polarity).

This keeps the behavior explicit at each reconcile decision point and avoids a second translation layer that can drift from the real lifecycle logic.

Final Conditions

The final v1beta2 conditions added for HetznerBareMetalHost are:

Constant	Type	Polarity	Notes
HetznerBareMetalHostReadyV1Beta2Condition	clusterv1.ReadyV1Beta2Condition	Positive	Summary condition
HetznerBareMetalHostCredentialsAvailableV1Beta2Condition	CredentialsAvailable	Positive	True when the SSH credentials in the referenced secret are valid
HetznerBareMetalHostRobotCredentialsAvailableV1Beta2Condition	RobotCredentialsAvailable	Positive	True when the Hetzner Robot API credentials are valid and reachable
HetznerBareMetalHostRootDeviceHintsValidatedV1Beta2Condition	RootDeviceHintsValidated	Positive	True when the configured root device hints match the discovered hardware
HetznerBareMetalHostProvisionSucceededV1Beta2Condition	ProvisionSucceeded	Positive	True when the host has reached OperatingSystemRunning
HetznerBareMetalHostDeletingV1Beta2Condition	clusterv1.DeletingV1Beta2Condition	Negative	Dedicated deletion signal for HetznerBareMetalHost
HetznerBareMetalHostRobotRateLimitExceededV1Beta2Condition	RobotRateLimitExceeded	Negative	True when the Robot API rate limit has been exceeded. Set to False on every successful reconcile (happy path setter).