chore(platform): sincroniza platform/ com o monorepo

platform/monitoring/application.yaml

@@ -60,6 +60,33 @@ spec:
             requests:
               cpu: 50m
               memory: 128Mi
+        # ── os tres CRITICAL que o k3s faz mentir (2026-09-21) ─────────────
+        #
+        # `KubeProxyDown`, `KubeSchedulerDown` e `KubeControllerManagerDown`
+        # estavam disparando em PERMANENCIA, e sao FALSOS: o k3s roda esses tres
+        # componentes EMBUTIDOS no processo do servidor e nao expoe as portas de
+        # metrica que o chart procura (10249/10259/10257). Nao ha o que consertar
+        # no cluster — o chart e que assume um Kubernetes "de pecas separadas".
+        #
+        # Por que desligar, e nao conviver: **tres criticos permanentes ensinam
+        # todo mundo a ignorar alerta**. No dia em que o Alertmanager existir,
+        # eles seriam a primeira coisa a chegar, e chegariam para sempre — e o
+        # canal nasceria desacreditado.
+        #
+        # Isto NAO desliga vigilancia nenhuma de verdade: com o controlador ou o
+        # scheduler fora, o no inteiro cai, e disso o `up` do kubelet e o
+        # `AthleticMapTenantPodNotReady` falam alto.
+        kubeProxy:
+          enabled: false
+        kubeScheduler:
+          enabled: false
+        kubeControllerManager:
+          enabled: false
+        # Mesmo caso: o etcd do k3s e embutido (SQLite/etcd interno) e nao
+        # responde na porta que o chart espera. Ja vinha desligado no chart para
+        # este arranjo; explicito aqui para nao voltar numa atualizacao.
+        kubeEtcd:
+          enabled: false
   destination:
     server: https://kubernetes.default.svc
     namespace: monitoring