docs(readme): nota de serialización/recuperación del deploy + fix drift timeout 7m->10m

Espeja el fix de CI del repo IDP (TENANT-BUILD-NO-CONCURRENCY-GUARD).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

README.md

@@ -7,6 +7,11 @@ Alembic, frontend estático en `/demo`, Helm chart, workflow de CI y manifiesto
 de contrato con la plataforma. Cuando se materializa este template para tu
 tenant, los placeholders en mayúsculas se sustituyen automáticamente.
 
+> **Página de bienvenida:** al provisionarse, tu plataforma sirve una página de
+> bienvenida en `/` con instrucciones de uso. **En cuanto hagas tu primer
+> `commit` + `push`, tu desarrollo reemplaza esa página** — define tu propio
+> handler de `/` (en `code/app/main.py` o en `code/app/routers/`).
+
 > **Contrato del shape:** ver `coralware-shape.yaml` en la raíz. Define los
 > endpoints obligatorios, la BD esperada y la versión del shape. No elimines
 > ese archivo — la plataforma lo lee.
@@ -60,7 +65,13 @@ El workflow del tenant sigue este orden en cada `git push`:
 |------|--------|--------|
 | 1 | `bash scripts/pre-helm-detach.sh` | Migración chart 1.0.0 → 1.1.0: si el AddonClaim tiene labels/annotations de un release Helm previo, las quita. Idempotente: skip si no aplica. Sunset tras ~2 semanas. |
 | 2 | `kubectl apply -f manifests/addonclaim.yaml` (con `sed` para placeholders) | Crea o actualiza el `AddonClaim`. Idempotente. `addon-provisioner` empieza a reconciliar en paralelo. |
-| 3 | `helm upgrade --install <release> ./helm/<APP_NAME> --wait --timeout 7m` | Aplica el chart Helm. Los hooks `pre-install,pre-upgrade` corren en orden de `hook-weight` (ver tabla abajo). El Job Alembic espera al Secret. |
+| 3 | `helm upgrade --install <release> ./helm/<APP_NAME> --wait --timeout 10m` | Aplica el chart Helm. Los hooks `pre-install,pre-upgrade` corren en orden de `hook-weight` (ver tabla abajo). El Job Alembic espera al Secret. |
+
+> **Deploys serializados + auto-recuperación:** el workflow tiene un guard
+> `concurrency` por repo, así que dos `git push` seguidos se **encolan** (no corren
+> el `helm upgrade` en paralelo). Si un deploy quedó a medias (cancelado), el
+> siguiente run **detecta y recupera** el release atascado (`pending-install` →
+> reinstala; `pending-upgrade` → rollback) antes de reintentar.
 
 El chart usa hooks `pre-install,pre-upgrade` con `hook-weight` para garantizar
 el orden de creación de SUS recursos (sin AddonClaim — ese vive fuera).