feat(plataforma): o provisionamento passa a LER o repositorio GitOps

A etapa MANIFESTOS_GERADOS renderiza o molde para tenants/<nome> numa copia de
trabalho, e o pod obtem essa copia clonando o Gitea na subida. Clonar e leitura.

Escrever continua fora de alcance, de proposito: empurrar no ramo padrao E o
deploy, e depende de uma credencial que ainda nao existe.

O Gitea aceita clone ANONIMO deste repositorio (conferido com git ls-remote sem
credencial), entao a etapa 1 funciona antes de a credencial de escrita existir.

A MESMA armadilha de rede, pela TERCEIRA vez. De dentro do pod, antes desta
politica: HTTP 000, exit 7. O ipBlock 10.43.0.0/16 da deny-cross-tenant cobre o
ClusterIP do Gitea e nao adianta — o k3s avalia DEPOIS do DNAT, e ali o destino
ja e o IP do POD.

Aconteceu com a API do Kubernetes em 20/09, com o sealed-secrets hoje mais cedo,
e agora aqui. E regra deste cluster, nao coincidencia.

Estreita: so o servico-captacao, so o POD do Gitea por rotulo (namespaceSelector
sozinho abriria a 3000 do namespace inteiro, onde tambem vivem o Valkey e o
runner de CI), so a 3000, so saida.

tenants/plataforma/19-netpol-gitea.yaml

@@ -0,0 +1,62 @@
+# =============================================================================
+# P5.3 — o provisionamento LE o repositorio GitOps.
+#
+# ── POR QUE, E O QUE ISTO NAO DA ────────────────────────────────────────────
+#
+# A etapa `MANIFESTOS_GERADOS` renderiza o molde (`moldes/consolidado`) para
+# `tenants/<nome>`, numa copia de trabalho do repositorio. O pod obtem essa
+# copia clonando o Gitea na subida — e clonar e LEITURA.
+#
+# **Escrever continua fora de alcance**, e de proposito: empurrar no ramo padrao
+# E o deploy (o ArgoCD esta com `automated` e `selfHeal`), e isso depende de uma
+# credencial que ainda nao existe. Esta politica nao muda nada disso; ela so
+# permite ler.
+#
+# O Gitea aceita clone ANONIMO deste repositorio — conferido em 2026-09-22 com
+# `git ls-remote` sem credencial. Por isso a etapa 1 funciona antes de a
+# credencial de escrita existir.
+#
+# ── A MESMA ARMADILHA, PELA TERCEIRA VEZ ────────────────────────────────────
+#
+# Medido de dentro do pod do `servico-captacao`, antes desta politica:
+#
+#     curl http://gitea-http.gitea.svc:3000/...  ->  HTTP 000, exit 7
+#
+# A `deny-cross-tenant` libera `ipBlock: 10.43.0.0/16`, que cobre o ClusterIP do
+# Gitea — e nao adianta: **o controlador de rede do k3s avalia a politica DEPOIS
+# do DNAT**, e ali o destino ja e o IP do POD (10.42.x.x).
+#
+# Aconteceu com a API do Kubernetes em 2026-09-20, com o controlador do
+# sealed-secrets em 2026-09-22, e agora aqui. **E regra deste cluster, e nao
+# coincidencia:** `ipBlock` com ClusterIP nao libera nada para outro namespace;
+# atravessar exige `namespaceSelector` + `podSelector`.
+#
+# ── POR QUE ESTA REGRA E ESTREITA ───────────────────────────────────────────
+#
+# `podSelector` por app: so o `servico-captacao` provisiona tenant. O destino e
+# o POD do Gitea, por rotulo — `namespaceSelector` sozinho abriria a 3000 de
+# todo o namespace `gitea`, onde tambem vivem o Valkey e o runner de CI.
+#
+# Saida apenas: o Gitea nunca inicia conversa conosco.
+# =============================================================================
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: egress-gitea
+  namespace: plataforma-prod
+spec:
+  podSelector:
+    matchLabels:
+      app: servico-captacao
+  policyTypes: [Egress]
+  egress:
+    - to:
+        - namespaceSelector:
+            matchLabels:
+              kubernetes.io/metadata.name: gitea
+          podSelector:
+            matchLabels:
+              app: gitea
+      ports:
+        - port: 3000
+          protocol: TCP