fix(ecommerce): sacar cache de fetch que competia contra force-dynamic

medusaFetch() usaba next:{revalidate:60,tags:["medusa-products"]}, cache
en memoria por-pod que sobrevivia a force-dynamic en las paginas que lo
consumen. Con frontend-deploy en 2 replicas sin cacheHandler compartido,
el POST de /api/revalidate del subscriber de Medusa solo llegaba a uno
de los dos pods, dejando al otro sirviendo datos viejos hasta que el TTL
expirara solo -- reportado por el usuario: ediciones manuales de imagen
no se reflejaban en el storefront, pero la importacion por CSV (mucho
mas lenta) si, porque el TTL tenia tiempo de sobra para expirar en
ambos pods.

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.268
           # 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/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) {