fix(platform): per-CRD SSA annotation — ArgoCD App-level ServerSideApply=true falls back to CSA on existing resources, exceeding 262 KiB annotation limit on KEDA scaledjobs/scaledobjects

Chart.yaml

@@ -23,8 +23,8 @@ description: |
       Git).
 
 type: application
-version: 0.7.5
-appVersion: "0.7.5"
+version: 0.7.6
+appVersion: "0.7.6"
 
 # All 6 subcharts now resolve from registry.odoosky.cloud (mirrored
 # 2026-05-08, KEDA stack added 2026-05-09). Mirror-first discipline

values.yaml

@@ -341,11 +341,18 @@ keda:
   # newly-onboarded server gets CRDs on first sync.
   # KEDA puts CRDs in templates/crds/ (not chart/crds/), so they
   # need to flow through helm template — which they do once this is
-  # set. ArgoCD's App-level ServerSideApply=true sync option (set in
-  # backend/cmd/api/server_adapters.go:108) handles the 262 KiB
-  # annotation overflow these CRDs would otherwise hit.
+  # set. ArgoCD's App-level ServerSideApply=true sync option SHOULD
+  # cover the 262 KiB annotation overflow these CRDs would hit with
+  # client-side apply (scaledjobs + scaledobjects each blow the limit
+  # because their schemas are huge), but ArgoCD's App-level setting
+  # falls back to client-side for resources that already exist with
+  # a different field-manager. Belt-and-suspenders: also annotate
+  # each CRD per-resource so the SSA path is taken regardless of
+  # who owned the field-manager first.
   crds:
     install: true
+    additionalAnnotations:
+      argocd.argoproj.io/sync-options: ServerSideApply=true
   # operator + adapter + webhook — keep CPU/RAM modest. KEDA polls
   # event sources every pollingInterval (default 30s); on a cluster
   # with no ScaledObjects it does no work.