mirror git: el poblador reporta el error real de git, no una conjetura

Imprimía siempre «upstream no da el commit» pasara lo que pasara. En la primera tanda marcó así a
diffutils, findutils-xargs y kustomize, cuyos commits se traen a mano sin problema: era transitorio.
Ahora bundle() devuelve (ruta, motivo) con el stderr del paso que falló.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o

docs/adr/0013-mirror-de-fuentes.md

@@ -205,4 +205,12 @@ eso el silencio se paga con comentarios explícitos en el código.
   hoy eso lo dispara una persona corriendo `mirror-git-poblar.sh`, no el latido.
 - Qué hacer con los repos cuyo servidor **no permite fetch por SHA suelto**
   (`uploadpack.allowReachableSHA1InWant` desactivado): ahí el `--depth 1` del commit exacto falla y
-  hay que caer a un clon completo. El poblador los reporta como `✗ upstream no da el commit`.
+  hay que caer a un clon completo.
+
+  El poblador reporta el **stderr real de git**, no una conjetura. Lo escribí al revés la primera
+  vez — imprimía siempre `✗ upstream no da el commit` — y en la primera tanda marcó así a tres
+  recetas (`diffutils`, `findutils-xargs`, `kustomize`) cuyos commits **sí se traen a mano**. Un
+  fallo en ese punto puede ser el servidor negando el sha, pero también un timeout, DNS o un
+  rate-limit de GitHub, y cada uno se arregla distinto. **Un diagnóstico hardcodeado convierte un
+  fallo transitorio en una conclusión falsa sobre upstream**, que es exactamente el error que ya
+  costó caro en la ruta relativa del bundle.