monitoring: Fase 2, el kube-prometheus-stack pasa a ArgoCD

El chart era un release Helm gestionado a mano (helm upgrade) desde abril.
Ahora lo gestiona su propia Application con source Helm, version clavada a
83.2.0 (la que ya corria: esto es una adopcion, no una actualizacion).

Los valores se mudan de values-kube-prometheus-stack.yaml al valuesObject de
la Application, con sus comentarios: ahi esta el historial de los retoques a
mano que se recuperaron en julio (alerting, SSO de Authentik, token de
Telegram), y perderlo seria perder el mapa. Inline y no multi-source $values
porque ese montaje se auto-podo la Application de infisical el 2026-06-18, y
tener los valores en dos sitios es la deriva que veniamos a matar.

La adopcion se verifico ANTES de activar el auto-sync: aplicada sin
syncPolicy, ArgoCD daba 96/97 Synced sin haber sincronizado nunca. El que
faltaba era el Deployment de Grafana, y no por deriva: el render del subchart
no declara managed-by: Helm ni el restartedAt del podTemplate, asi que el
merge a 3 bandas del cliente los habria BORRADO (reinicio de Grafana + Helm
perdiendo la propiedad del objeto). Con ServerSideApply/ServerSideDiff ArgoCD
solo toca lo que declara: 97/97 Synced, cero operaciones de sync, cero pods
reiniciados. selfHeal probado con replicas 1->2 en kube-state-metrics,
revertido en 11s.

skipCrds: true a proposito: ArgoCD pasa --include-crds por defecto y los 10
CRD de monitoring.coreos.com no los gestiona nadie hoy. Contrapartida
documentada en el fichero: al subir de chart hay que aplicarlos a mano.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

monitoring/argocd-app.yaml

@@ -4,11 +4,13 @@
 # mezcla TRES dueños distintos y solo uno es nuestro.
 #
 #   A) Lo que escribimos nosotros  -> el include de aquí abajo, ArgoCD manda.
-#   B) Lo que genera el chart      -> kube-prometheus-stack (release Helm viva).
-#      Meterlo aquí daría DOS dueños al mismo objeto y reproduciría la deriva
-#      del three-way merge que ya se comió el alerting y el token de Telegram.
-#      Adoptarlo va aparte (source Helm + values-kube-prometheus-stack.yaml,
-#      borrando de git los ~40 renderizados). Pendiente = Fase 2.
+#   B) Lo que genera el chart      -> kube-prometheus-stack. Sigue SIN estar en
+#      esta lista, y con razón: gestionarlo desde aquí como manifiestos sueltos
+#      daría DOS dueños al mismo objeto y reproduciría la deriva del three-way
+#      merge que ya se comió el alerting y el token de Telegram. Desde la Fase 2
+#      (2026-07-25) lo gestiona su propia Application con source Helm ->
+#      argocd-app-kube-prometheus-stack.yaml, y los ~40 renderizados que había
+#      volcados en git se han borrado. Un solo dueño, el chart.
 #   C) Lo que fabrican los controladores solos -> serviceaccount-default,
 #      configmap-kube-root-ca.crt y el rulefiles-0 (lo genera el
 #      prometheus-operator desde los PrometheusRule). En git no pintan nada;
@@ -44,7 +46,7 @@ spec:
       # Lista blanca explícita. Al añadir un fichero nuestro a monitoring/ hay
       # que añadirlo AQUÍ o ArgoCD lo ignora. Y al revés: sacar un fichero de
       # esta lista con prune:true activo BORRA el recurso del cluster.
-      include: "{argocd-app.yaml,configmap-grafana-alerting.yaml,configmap-chemavx-homelab-overview.yaml,deployment-uptime-kuma.yaml,service-uptime-kuma.yaml,pvc-uptime-kuma-pvc.yaml,ingress-uptime-kuma.yaml,ingress-uptime-kuma-redirect.yaml,ingress-prometheus.yaml,infisical-grafana-telegram.yaml}"
+      include: "{argocd-app.yaml,argocd-app-kube-prometheus-stack.yaml,configmap-grafana-alerting.yaml,configmap-chemavx-homelab-overview.yaml,deployment-uptime-kuma.yaml,service-uptime-kuma.yaml,pvc-uptime-kuma-pvc.yaml,ingress-uptime-kuma.yaml,ingress-uptime-kuma-redirect.yaml,ingress-prometheus.yaml,infisical-grafana-telegram.yaml}"
   destination:
     server: https://kubernetes.default.svc
     namespace: monitoring