Validate storage connection on Storage create and surface errors in status (describe)

Summary

When a Storage resource is created/applied, validate that the operator can actually connect to the configured storage backend. If the connection check fails, record the error in the resource's status so it is visible via kubectl describe storage <name>.

Motivation

Today a Storage can be applied with invalid or unreachable configuration (wrong credentials, bad endpoint/host, missing bucket, network failure) and nothing surfaces the problem until a backup job tries to use it and fails. Users have no immediate feedback on whether a storage definition is usable.

Current state

• StorageStatus is empty — no observed state is recorded (api/v1/storage_types.go:181).
• There is no Storage controller/reconciler; only BackupReconciler references storages (get;list;watch) and validates that StorageRefs are non-empty (internal/controller/backup_controller.go).

Proposed behavior

• On Storage create/update, perform a lightweight connectivity/auth check against the backend (per spec.type), e.g. verify endpoint reachability and credentials/bucket access without writing real backup data.
• Write the outcome to StorageStatus:
  • A Ready condition (status: True/False, reason, message), and/or a phase + human-readable message.
  • On failure, include the error message so it shows up in kubectl describe storage <name> events/conditions.
• Re-validate when the spec changes (track observedGeneration).

Acceptance criteria

• StorageStatus gains fields/conditions to represent connection state and error message.
• A reconciler (or the existing flow) runs the connection check and updates status.
• A misconfigured Storage shows the failure reason in kubectl describe.
• A valid Storage shows a Ready/healthy state.
• CRD manifests regenerated (note: charts/ CRDs are not auto-synced by make manifests and must be hand-synced).

Open questions

• Which backends get a real connectivity check vs. config-only validation in the first pass?
• Should the check run periodically (requeue) or only on spec change?

Start with StorageStatus in api/v1/storage_types.go and the storage references and validation flow in internal/controller/backup_controller.go; determine how the proposed reconciler fits the current operator structure. Review the backend-specific scope in the issue and run make manifests when schema changes are defined. Done means a misconfigured Storage exposes a failure through describe, a valid one reports healthy, and charts/ CRDs are hand-synced.