docs: record the production verification of both fixes

Adds the production evidence for commit 4281567 (`test:pwa` passing against the HTTPS
domain, the install button present with the chunk delayed, the chart running as a
CSSAnimation, smoke 16/16) and what this deploy taught about the setup:

- Auto-deploy webhooks are active on BOTH remotes, so pushing to gitea and github in
  sequence queues two concurrent deploys of the same commit.
- `force=true` is never needed after a push; it stops the container before building and
  adds avoidable downtime.
- Measured 241s of unavailability for this deploy — explicitly not attributed to cold
  start, since a second deploy was building concurrently.
- This Coolify instance only answers on collection endpoints; everything per-resource
  404s, so container env vars and logs are not readable over the API.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

.superpowers/sdd/progress.md

@@ -247,6 +247,36 @@ Gates tras los dos arreglos: typecheck 0 · test:landing 13/13 · test:pwa passe
 hallazgos · audit:visual 62 pantallas 0 fallos 0 errores · unit 39/39 · e2e 33/33 · admin 17/17 ·
 booking 12/12.
 
+VERIFICADO EN PRODUCCIÓN (commit `4281567`, bundle `index-CGg6by-0.js`):
+- `test:pwa` con `PWA_BASE_URL=https://agendamax.urieljareth.org` **passed** — es exactamente el test
+  que fallaba antes del arreglo.
+- La reproducción con el chunk retrasado 1.5s contra producción: evento sintético a los 471ms, botón
+  «Instalar AgendaMax» PRESENTE (antes AUSENTE).
+- La gráfica: `getAnimations()` devuelve `CSSAnimation` en producción, y el muestreo confirma que la
+  línea se dibuja.
+- Smoke completo 16/16.
+
+### Sobre desplegar aquí, para la próxima
+
+- **El auto-deploy por webhook está activo en los DOS remotos.** Pushear a gitea y a github seguido
+  encoló dos deploys simultáneos del mismo commit (150 y 151). Es inofensivo —misma imagen— pero
+  duplica el trabajo del servidor y añade un swap de contenedor extra. Si solo se quiere un deploy,
+  pushear a uno y dejar que el otro se sincronice después.
+- **Nunca hace falta `force=true` después de un push**; el webhook ya construye. El force detiene el
+  contenedor antes de compilar y añade una caída evitable.
+- Ventana de indisponibilidad medida en este despliegue: **241s** desde el primer 502 hasta el primer
+  200 en `/api/health`. Ojo con atribuirla: había un segundo deploy construyendo a la vez, así que es
+  la ventana del despliegue completo, **no** una medida limpia del arranque en frío.
+- Hecho de código relacionado, sin medir y sin tocar: `tsx` está en `devDependencies` y la etapa de
+  runtime del Dockerfile hace `npm ci --omit=dev`, así que la imagen no lo contiene y
+  `CMD ["npx","tsx",...]` lo resuelve del registro **en cada arranque de contenedor**. Eso alarga el
+  arranque y hace que levantar dependa de que npm sea alcanzable. Moverlo a `dependencies` es una
+  línea; no se hizo porque nadie lo pidió y cambia la imagen de runtime.
+- La API de esta instancia (Coolify 4.1.2) solo responde en endpoints de colección: `/resources`,
+  `/projects`, `/servers`, `/deployments` y `/deployments/{uuid}`. Todo lo per-resource
+  (`/applications/{uuid}`, `/…/envs`, `/…/logs`) devuelve 404, así que no se pueden leer las
+  variables de entorno ni los logs del contenedor por API.
+
 FOLLOW-UPS DIFERIDOS:
 1. `/login` en desktop deja un vacío bajo la tarjeta del formulario (columnas de altura muy distinta).
    No es un defecto medible; revisar si molesta en uso real.