fix(ci): condicion de carrera en el chequeo de promocion GitOps

Con el runner corriendo 1 job a la vez (capacity: 1), cuando 2+
pipelines comparten el mismo commit disparador, el primero en terminar
deja su propio commit de GitOps en main -- los siguientes veian 'main
ya no es igual a mi commit' y se saltaban su propia promocion, aunque
era seguro promocionar. Visto en vivo: Frontend construyo, escaneo y
firmo v1.0.119 pero el manifiesto seguia en v1.0.104 (Promocion GitOps:
false). Fix en los 3 workflows: git merge-base --is-ancestor en vez de
comparacion exacta de SHA. Bump manual de frontend a v1.0.119 (la
version que ya estaba lista, sin desplegar). Documentado el limite
conocido de este fix en el playbook de la migracion.

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

.gitea/workflows/deploy-docs.yaml

@@ -335,6 +335,10 @@ jobs:
             --insecure-ignore-tlog=true \
             "${IMAGE_NAME}@${{ steps.push.outputs.digest }}"
 
+      # merge-base --is-ancestor, no comparación exacta -- ver el
+      # comentario largo en build.yaml sobre por qué (condición de
+      # carrera real con 2+ pipelines compartiendo un commit, visto en
+      # vivo 2026-08-17).
       - name: Verificar promoción segura
         id: promotion
         shell: bash
@@ -346,7 +350,7 @@ jobs:
           CURRENT_SHA="${{ github.sha }}"
           REMOTE_SHA="$(git rev-parse origin/main)"
 
-          if [ "${CURRENT_SHA}" = "${REMOTE_SHA}" ]; then
+          if git merge-base --is-ancestor "${CURRENT_SHA}" origin/main; then
             echo "promote=true" >> "$GITHUB_OUTPUT"
           else
             echo "promote=false" >> "$GITHUB_OUTPUT"