fix(keycloak): one owner for the keycloak ServiceMonitor (26.8 operator 409 loop blocks Flux)

The 26.x Keycloak operator creates its own ServiceMonitor named after the
CR (keycloak/keycloak) when metrics are enabled; spec.serviceMonitor.enabled
defaults true. That collides with the Flux-owned platform/keycloak/
servicemonitor.yaml: the operator's PATCH 409s, it exhausts retries, the CR
stays Ready=False/HasErrors=True, and platform-config (wait: true) stalls
every downstream Kustomization.

Keep the repo's ServiceMonitor (conformance L0/L2 and the dashboard are
written against it; the operator's scrapes the same port 9000 /metrics) and
set spec.serviceMonitor.enabled: false.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

platform/keycloak/keycloak-instance.yaml

@@ -38,6 +38,20 @@ spec:
   ingress:
     enabled: false                         # exposed via Gateway API HTTPRoute (httproute.yaml), not the
                                            # operator's built-in Ingress
+  # --- ONE OWNER for the `keycloak` ServiceMonitor: this repo (servicemonitor.yaml), not the operator.
+  #     Since 26.x the operator creates its OWN ServiceMonitor, named after this CR (`keycloak`, i.e.
+  #     the SAME name/namespace as ours), whenever metrics-enabled=true and the CRD exists —
+  #     spec.serviceMonitor.enabled defaults TRUE. On 2026-11-08, right after the 26.0.6 -> 26.8.2
+  #     bump, its server-side apply onto our Flux-owned object failed `409 Conflict`, the operator
+  #     exhausted retries, the CR sat Ready=False/HasErrors=True, and `platform-config` (wait: true,
+  #     so it health-checks this CR) stalled every Kustomization downstream of it. Ours is kept
+  #     because the L0 servicemonitor-ports-resolve and L2 keycloak-monitored conformance tests and
+  #     the dashboard's up{namespace="keycloak"} are written against it; the operator's would scrape
+  #     the same thing (management port 9000, /metrics, 30s). Do NOT flip this to true without
+  #     deleting servicemonitor.yaml in the same change — two owners of one object is a fight
+  #     (cf. the default-deny NetworkPolicy drift loop).
+  serviceMonitor:
+    enabled: false
   # --- Hardening + observability options (docs/15). Brute-force detection is a REALM setting
   #     (bruteForceProtected in the realm import); these enable health + metrics endpoints. ---
   additionalOptions:

platform/keycloak/servicemonitor.yaml

@@ -8,6 +8,9 @@
 # /metrics) once metrics-enabled/health-enabled are set (see keycloak-instance.yaml additionalOptions).
 # We select the operator-created keycloak-service (which selects the Keycloak pods) and scrape the pods'
 # management port by number via targetPort.
+# SOLE OWNER: the operator's own ServiceMonitor (same name `keycloak`) is switched OFF in
+#   keycloak-instance.yaml (spec.serviceMonitor.enabled: false) — 26.x defaults it ON and its apply
+#   409-looped against this object on 2026-11-08. Keep exactly one of the two.
 # TODO(WS-SEC, bring-up): confirm the management port number/name the operator exposes (9000 default)
 #   and adjust targetPort if the pinned operator changes it. The KeycloakDown / KeycloakDatabaseDown
 #   alerts (platform/monitoring/alerts.yaml) key on kube-state-metrics and fire regardless of this SM.