fix(ci,ecommerce): escanear el manifiesto renderizado y endurecer readOnlyRootFilesystem del frontend

- Trivy IaC escaneaba solo el patch aislado de Kustomize
  (workloads/ecommerce/frontend/patches/deployment.yaml), no lo que
  realmente corre en el clúster. Eso generaba falsos positivos en todo
  lo heredado del base remoto de platform-templates (runAsNonRoot,
  seccompProfile) porque el patch nunca los repite. Se instala kubectl,
  se renderiza el kustomization completo y se escanea ese output.
- readOnlyRootFilesystem pasa de false a true en el contenedor del
  frontend: revisando next.config.ts (optimización de imágenes) y
  app/api/revalidate/route.ts (revalidateTag sin cache handler custom),
  la imagen sí escribe a ./.next/cache en runtime. Se agregan volúmenes
  emptyDir para .next/cache y /tmp.

.gitea/workflows/build.yaml

@@ -122,11 +122,12 @@ jobs:
     needs: gitleaks
     if: github.event_name == 'push'
     runs-on: ubuntu-latest
-    timeout-minutes: 20
+    timeout-minutes: 30
 
     env:
       APP_DIR: workloads/ecommerce
       MANIFEST_FILE: workloads/ecommerce/frontend/patches/deployment.yaml
+      KUSTOMIZE_DIR: workloads/ecommerce/frontend
       IMAGE_NAME: gitea.cruzcloud.net/devops/ecommerce-frontend
 
     steps:
@@ -276,6 +277,32 @@ jobs:
           chmod +x /tmp/trivy
           /tmp/trivy version
 
+      - name: Instalar kubectl
+        shell: bash
+        run: |
+          set -euo pipefail
+          KUBECTL_VERSION="v1.31.2"
+          curl -sSfL \
+            "https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl" \
+            -o /tmp/kubectl
+          chmod +x /tmp/kubectl
+          /tmp/kubectl version --client
+
+      # ${MANIFEST_FILE} es solo el patch de Kustomize del Deployment, no el
+      # manifiesto que de verdad corre en el clúster -- escanearlo directo
+      # generaba falsos positivos en todo lo que hereda del base remoto de
+      # platform-templates (runAsNonRoot, seccompProfile), porque ese patch
+      # nunca repite lo que ya trae el base (visto en vivo 2026-08-24:
+      # comparando el patch aislado contra el output real de
+      # "kubectl kustomize", 2 de 5 hallazgos desaparecían). Renderizamos el
+      # kustomization completo (${KUSTOMIZE_DIR}, que sí trae el base vía
+      # git remoto) y escaneamos eso.
+      - name: Renderizar manifiesto Kustomize
+        shell: bash
+        run: |
+          set -euo pipefail
+          /tmp/kubectl kustomize "${KUSTOMIZE_DIR}" > /tmp/frontend-rendered.yaml
+
       # Escanea el manifiesto Kubernetes real del frontend (no la imagen):
       # contenedores como root, falta de resource limits, falta de
       # readiness/liveness probes, etc. Informativo por ahora — no bloquea
@@ -287,7 +314,7 @@ jobs:
           /tmp/trivy config \
             --severity CRITICAL,HIGH,MEDIUM \
             --exit-code 0 \
-            "${MANIFEST_FILE}"
+            /tmp/frontend-rendered.yaml
 
       # Instalado directo con pip (no como container aparte): el runner de
       # Gitea ejecuta cada job ya dentro de un contenedor propio que habla
@@ -367,6 +394,12 @@ jobs:
 
       # CRITICAL bloquea el pipeline: no se sube una imagen con una CVE
       # crítica conocida y con fix disponible.
+      # --timeout 15m0s: el default de Trivy (5m) dejó de alcanzar también
+      # para el frontend (visto en vivo: "context deadline exceeded" a los
+      # ~4m45s, en un run justo después de terminar el docker build, con
+      # el host bajo la misma inestabilidad de nodo vista ese día). Mismo
+      # fix ya aplicado en build-medusa.yaml el 2026-08-16 -- el supuesto
+      # de que el frontend era más liviano y no lo necesitaba ya no vale.
       - name: Escanear imagen (Trivy) — CRITICAL bloquea
         shell: bash
         run: |
@@ -375,6 +408,7 @@ jobs:
             --severity CRITICAL \
             --exit-code 1 \
             --ignore-unfixed \
+            --timeout 15m0s \
             "${IMAGE_NAME}:${{ steps.vars.outputs.VERSION }}"
 
       # HIGH solo informa por ahora — no bloquea mientras aprendemos a leer
@@ -387,6 +421,7 @@ jobs:
             --severity HIGH \
             --exit-code 0 \
             --ignore-unfixed \
+            --timeout 15m0s \
             "${IMAGE_NAME}:${{ steps.vars.outputs.VERSION }}"
 
       # SBOM de la imagen que ya pasó el gate de CRITICAL — describe

workloads/ecommerce/frontend/patches/deployment.yaml

@@ -25,7 +25,7 @@ spec:
         runAsUser: 1001
       containers:
         - name: app
-          image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.129
+          image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.133
           env:
             - name: HEADLESS_PROVIDER
               value: medusa
@@ -64,9 +64,20 @@ spec:
           # binario de node para esto, pero eso solo funciona si el
           # bounding set del contenedor lo permite -- drop: ALL del base
           # lo bloquea igual, root o no root. Mismo motivo que docs-portal.
+          #
+          # readOnlyRootFilesystem: true -- revisado en código (2026-08-24,
+          # aún no probado en vivo con este cambio) que esta imagen sí
+          # escribe a disco en runtime, no solo en build: el servidor
+          # standalone de Next.js cachea a ./.next/cache tanto el
+          # optimizador de imágenes (next.config.ts trae remotePatterns,
+          # sin "unoptimized: true") como el revalidateTag("medusa-products")
+          # de app/api/revalidate/route.ts (cache handler por default, sin
+          # uno custom tipo Redis). De ahí los dos volumeMounts de abajo:
+          # sin ellos, con root filesystem de solo lectura, ambas rutas
+          # fallarían al intentar escribir.
           securityContext:
             allowPrivilegeEscalation: false
-            readOnlyRootFilesystem: false
+            readOnlyRootFilesystem: true
             capabilities:
               drop:
                 - ALL
@@ -79,3 +90,13 @@ spec:
             limits:
               cpu: "1"
               memory: 768Mi
+          volumeMounts:
+            - name: next-cache
+              mountPath: /app/.next/cache
+            - name: tmp
+              mountPath: /tmp
+      volumes:
+        - name: next-cache
+          emptyDir: {}
+        - name: tmp
+          emptyDir: {}