takana: la unit del worker fija TAKANA_DIR ademas de HAMMER_DIR

Medido: esta unit era el UNICO sitio fuera del repo que traia una variable
vieja puesta (Environment=HAMMER_DIR=/opt/hammer), y por eso es lo que impide
retirar la caida del codigo. Ahora fija las dos.

Se ponen las dos y no solo la nueva porque un script viejo —o una copia del
repo que todavia no sincronizo— solo mira HAMMER_DIR.

Desplegada y verificada en dev.gioser.net: daemon-reload + restart, servicio
active, y el entorno del servicio muestra las dos.

scripts/farm/hammer-farm.service

@@ -20,6 +20,14 @@ StartLimitBurst=3
 Type=simple
 WorkingDirectory=/opt/hammer
 Environment=HOME=/root
+# ADR 0016: se fijan LAS DOS mientras dure el renombre. Los scripts leen
+# ${TAKANA_DIR:-${HAMMER_DIR:-…}}, pero un script VIEJO —o una copia del repo
+# que todavía no sincronizó— sólo mira HAMMER_DIR. Medido el 2026-09-09: esta
+# unit era el ÚNICO sitio fuera del repo que traía una variable vieja puesta, y
+# es lo que hoy impide retirar la caída. Cuando el worker corra con TAKANA_DIR
+# y el resto de la flota también, se borra la segunda línea y recién ahí se
+# puede retirar la caída del código (etapa 6).
+Environment=TAKANA_DIR=/opt/hammer
 Environment=HAMMER_DIR=/opt/hammer
 # JOBS no se fija: el loop usa nproc por defecto (cada build usa 1 core por codegen-units=1).
 # Así, al REPOTENCIAR la caja (CCX13→CCX23/33), el worker auto-escala los slots sin tocar config.