fix(uptime-monitor): guard healthCheckExprs against absent status.conditions

An ExternalSecret has no status subresource until ESO's first reconcile
writes one. CEL raises "no such key" on a missing field rather than
returning false, so the unguarded expressions turned the startup window
into an evaluation error instead of "not ready yet".

Adds the same `has(status.conditions)` guard the other nine
healthCheckExprs in kubernetes/clusters/homelab already carry;
wordpress.yaml is the closest match, being the other conditions-based
(rather than phase-based) rule.

Refs REN-6.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

kubernetes/clusters/homelab/uptime-monitor.yaml

@@ -57,8 +57,15 @@ spec:
   healthCheckExprs:
     - apiVersion: external-secrets.io/v1
       kind: ExternalSecret
-      current: "status.conditions.exists(c, c.type == 'Ready' && c.status == 'True')"
-      failed: "status.conditions.exists(c, c.type == 'Ready' && c.status == 'False')"
+      # `has(status.conditions)` is not decoration. A just-created ExternalSecret
+      # has no `status` subresource until ESO's first reconcile writes one, and
+      # CEL raises "no such key" on a missing field rather than returning false —
+      # an unguarded expression turns that startup window into an evaluation
+      # error instead of "not ready yet". Same guard as the other nine
+      # healthCheckExprs in this directory; `wordpress.yaml` is the closest
+      # match, being the other conditions-based (rather than phase-based) rule.
+      current: "has(status.conditions) && status.conditions.exists(c, c.type == 'Ready' && c.status == 'True')"
+      failed: "has(status.conditions) && status.conditions.exists(c, c.type == 'Ready' && c.status == 'False')"
   dependsOn:
     # ESO itself, and the `uptime-monitor` namespace (declared centrally in
     # kubernetes/infrastructure/namespaces/namespaces.yaml).