chore: release v1.0.270 [skip ci]

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QMP7ULbxbsB5g1vELNAT3D

workloads/docs-portal/docs/decisiones/0010-pago-envio-reales-y-storefront.md

@@ -425,3 +425,27 @@ Resultados reales, uno por uno (código de cada prueba en
     un dispositivo real.
 21b. **Accesibilidad del checkout completo** por teclado (no solo el
     buscador) — tab order y foco visible en los 3 pasos.
+22. **Importación manual de imágenes no se refleja en el storefront**
+    (reportado por el usuario 2026-09-20): subir/editar imágenes de un
+    producto a mano (vs. importación por CSV, que sí funciona) no
+    aparece del lado del storefront. Falta reproducir contra el flujo
+    real de importación manual del admin de Medusa (ver
+    `temp-admin`/`ari-shopping-tienda` en memoria) y confirmar si es
+    caché (ISR de Next, `force-dynamic` ya está en la página de
+    producto — ver más arriba), staleness de Meilisearch (ver memoria
+    `search-inventory-staleness`, mismo síntoma de "el catálogo directo
+    sí, la búsqueda no") o algo específico del pipeline de importación
+    en `commerce-backend`.
+23. **En mobile, la visualización de imágenes de producto se corta y
+    obliga a scrollear** (reportado por el usuario 2026-09-20, con
+    captura real de `shop.cruzcloud.net` en un producto con múltiples
+    fotos). Toda la clase de bug de overflow por falta de `min-w-0` ya
+    se revisó en vivo en esta sesión y sigue presente en
+    `product-gallery.tsx` y `app/product/[slug]/page.tsx` — sospecha
+    sin confirmar: el modal "Zoom interactivo"
+    (`ProductGallery`/`DialogContent`, `min-h-[70vh]` +
+    `overflow-hidden`) en viewport móvil real, donde la barra de
+    direcciones de Chrome/Safari hace que `100vh` mida más que el área
+    visible real. Pendiente reproducir con un dispositivo real o
+    emulación de `visualViewport` (Playwright con viewport móvil no
+    replica el comportamiento dinámico de la barra de direcciones).

workloads/docs-portal/patches/deployment.yaml

@@ -25,7 +25,7 @@ spec:
         runAsNonRoot: false
       containers:
         - name: app
-          image: gitea.cruzcloud.net/devops/docs-portal:v1.0.267
+          image: gitea.cruzcloud.net/devops/docs-portal:v1.0.269
           # El base saca TODAS las capabilities. Probado en vivo y
           # revertido: con drop: ALL (aunque se agregue NET_BIND_SERVICE
           # de vuelta) el propio entrypoint de nginx:1.27-alpine falla al

workloads/ecommerce-staging/frontend/patches/deployment.yaml

@@ -26,11 +26,11 @@ spec:
         runAsUser: 1001
       containers:
         - name: app
-          image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.266
+          image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.270
           env:
             # Ver comentario en workloads/ecommerce/frontend/patches/deployment.yaml
             - name: APP_VERSION
-              value: v1.0.266
+              value: v1.0.270
             - name: HEADLESS_PROVIDER
               value: medusa
             # Backend COMPARTIDO con Producción a propósito (decisión del

workloads/ecommerce/lib/headless/providers/medusa.ts

@@ -111,14 +111,26 @@ async function medusaFetch<T>(
 
   const publishableKey = process.env.MEDUSA_PUBLISHABLE_KEY;
 
+  // Sin next.revalidate/tags a proposito (reportado por el usuario
+  // 2026-09-20: imagenes editadas a mano en Medusa no se reflejaban en
+  // el storefront, pero por CSV si). Causa real: frontend-deploy corre 2
+  // replicas sin cacheHandler compartido -- cada pod tenia su propio
+  // cache en memoria de este fetch (next.revalidate:60), y el POST de
+  // /api/revalidate (revalidateTag) del subscriber de Medusa solo le
+  // llegaba a UNO de los dos pods via el Service, dejando al otro
+  // sirviendo la respuesta vieja hasta que el TTL expirara solo. Una
+  // edicion puntual + revisar al toque tenia ~50% de chance de pegarle
+  // al pod stale; una importacion CSV (minutos de duracion) le daba
+  // tiempo de sobra al TTL para expirar en ambos pods, disimulando el
+  // mismo bug. Las paginas que consumen esto ya son force-dynamic /
+  // dinamicas por diseño (ver comentario en app/page.tsx y
+  // app/product/[slug]/page.tsx) -- este next.revalidate competia contra
+  // esa intencion en vez de cumplirla. Sin este bloque, Next 15 no
+  // cachea el fetch por default dentro de una ruta dinamica.
   const response = await fetch(url, {
     headers: publishableKey
       ? { "x-publishable-api-key": publishableKey }
       : undefined,
-    next: {
-      revalidate: 60,
-      tags: ["medusa-products"],
-    },
   });
 
   if (!response.ok) {