takana: las recetas que clonan el propio repo apuntaban a la URL renombrada

Rotura que introduje yo al renombrar el repo en gitea, y que no fallaba todavia
porque las tres tienen su artefacto sellado en cache:

  git ls-remote sergio/hammer.git  -> no responde
  git ls-remote sergio/takana.git  -> b393687d

hammerd, netup y portal-probe clonan el propio repo por ssh. Cualquier rebuild
de esas tres —o un hub nuevo sin store— habria muerto en el fetch.

El ArtifactHash NO se mueve, y esta comprobado receta por receta antes y despues
del cambio (48bbbe52, 8d093d74, 13ebb33d): la URL es locator y no entra en
hash_inputs, solo el commit (ADR 0013). Por eso mismo el arreglo es gratis.

Tambien el default de GITEA en espejo-setup.sh. git.tawasuyu.net y
git.gioser.net son la MISMA maquina (204.168.193.248), asi que el renombre le
aplica igual.

El espejo de GitHub sigue siendo sergiovelasquezzeballos/hammer: alla el repo no
se renombro. No rompe nada porque el push va por URL explicita, pero queda dicho.

scripts/espejo-setup.sh

@@ -41,7 +41,7 @@ cd "$ROOT"
 # hacía `--unset-all` y le cambiaba el destino canónico al clon sin decir nada, que es la clase de
 # cambio que no se nota hasta que un push va a donde no era. El fallback sólo aplica si no hay origin.
 GITEA="${GITEA:-$(git remote get-url origin 2>/dev/null)}"
-GITEA="${GITEA:-ssh://gitea@git.tawasuyu.net:2345/sergio/hammer.git}"
+GITEA="${GITEA:-ssh://gitea@git.tawasuyu.net:2345/sergio/takana.git}"
 
 CHECK=0
 [ "${1:-}" = "--check" ] && CHECK=1