ADR 0016: worker migrado, y corregida una recaida del barrido

El worker vive en /opt/takana con takana-farm.service, verificado por un ciclo
de build real alla y una cosecha completa aca.

Y queda anotada la recaida: el barrido ad-hoc de este mismo cambio no respeto
el aviso que este fichero tiene arriba y dio vuelta cuatro afirmaciones
HISTORICAS, dejandolo diciendo que a las 18:40 se reinicio takana-farm.service
cuando en ese momento se llamaba hammer-farm.service. Corregidas a mano. La
exclusion hay que ponerla en CADA barrido, no una sola vez.

docs/adr/0016-renombre-takana.md

@@ -93,7 +93,7 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con
    - ADRs y docs de diseño: texto, y `hammer` sigue funcionando. Van con la etapa 5.
 
    **Cómo converge el worker** (medido el 2026-09-09, no supuesto). Su checkout vive en
-   `/opt/hammer`, **no es un clon git** —lo pone el rsync de la siembra— y `takana-farm.service`
+   `/opt/hammer`, **no es un clon git** —lo pone el rsync de la siembra— y `hammer-farm.service`
    está `enabled` allá, corriendo `farm-worker-loop.sh` como servicio largo. En el momento del
    cambio el worker tenía scripts viejos y binario del 6-sep: **coherente**. Los dos estados
    intermedios también lo son, y por eso la 3a iba primero:
@@ -105,7 +105,7 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con
    La unit apunta a la RUTA DEL SCRIPT, no al binario, así que nada de la etapa 3 la toca. El
    nombre del fichero de unit y `/opt/hammer` son etapa 6.
 
-   **Convergido y comprobado (2026-09-09 18:40–18:45Z).** Reiniciado `takana-farm.service`, el
+   **Convergido y comprobado (2026-09-09 18:40–18:45Z).** Reiniciado `hammer-farm.service`, el
    worker compiló los dos binarios y **cerró un ciclo de build real con el nombre nuevo**:
    `✓ dunst b3:29a79859…`, BUILD-YIELD 1/1, 1 promovido. No es que «no se rompió nada visible»: el
    camino de construir y sellar se ejercitó entero.
@@ -197,7 +197,7 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con
    reescribir historia es peor que un mensaje incompleto. El detalle vive acá.)*
 
    **Congelados y verificados con controles:** `/opt/hammer`, `/var/lib/hammer`, `/usr/bin/hammer`,
-   `/mnt/vvv/hammer`, la URL de gitea, `takana-farm.service`, `hammer-live-install.sh`,
+   `/mnt/vvv/hammer`, la URL de gitea, `hammer-farm.service`, `hammer-live-install.sh`,
    `BRIEFING-hammer.md`, `hammerd`, `hammer-recover`, `HAMMER_LIVE`, `.hammer-zig-cc`,
    `.hammer-cargo-vendor` y dos identificadores más que aparecieron al barrer:
    - `hammer-build-state/1` — el `schema` del estado generado. Nadie lo valida, pero el valor de un
@@ -236,8 +236,30 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con
    - 🔒 **`/usr/bin/hammer` dentro del rootfs del producto** — está **dentro de un árbol que se
      hashea**. Moverlo cambia el hash del producto y obliga a rehacer el baseline del selfhost.
      Va junto con esa deuda, no antes.
-   - ⚠ **`takana-farm.service` y `/opt/hammer`** — despliegue coordinado en el worker: parar,
-     renombrar, `daemon-reload`, arrancar. Reversible, pero es hacia afuera.
+   - ✅ **`/opt/takana` y `takana-farm.service`** (2026-09-09 ~20:15Z). Sin montajes adentro esta
+     vez, así que el `mv` fue directo.
+
+     **El orden no era cosmético:** el hub siembra por `rsync` a una ruta fija, así que el cron se
+     sacó ANTES de mover. Al revés, la siguiente cosecha habría recreado `/opt/hammer` y el worker
+     quedaba **partido en dos árboles** sin que nada fallara.
+
+     Un detalle que el primer `sed` no casó: `systemctl restart hammer-farm` y
+     `journalctl -u hammer-farm` nombran la unit **sin el sufijo `.service`**.
+
+     **Verificado:** el worker cerró un ciclo de build real desde `/opt/takana` (`dunst` sellado,
+     1/1) y una cosecha completa del hub contra la ruta nueva pasó siembra, manifiesto, los nueve
+     grafos, `static-audit` (691 estáticos, MIENTEN 0) y estado pusheado.
+
+     **Dos referencias a `/opt/hammer` quedan a propósito porque siguen siendo ciertas:**
+     `docs/23-plan-rehasheo.md` describe rutas **embebidas en artefactos ya construidos** —sus
+     secciones `.debug` literalmente dicen `/opt/hammer/work`— y el HANDOFF de la noche de KDE es
+     registro. Cambiarlas haría que los documentos mientan sobre lo que hay en el disco.
+
+     ⚠ **Y una recaída, anotada porque es la misma trampa dos veces:** el barrido ad-hoc de este
+     mismo cambio (`git grep -l … | sed`) NO respetó el aviso de arriba y dio vuelta cuatro
+     afirmaciones **históricas** de este fichero, dejándolo diciendo que a las 18:40 se reinició
+     `takana-farm.service` cuando en ese momento se llamaba `hammer-farm.service`. Corregidas a
+     mano. La exclusión hay que ponerla en **cada** barrido, no una vez.
    - ✅ **`/mnt/vvv/hammer` → `/mnt/vvv/takana`, y el repo renombrado en gitea a `sergio/takana`**
      (2026-09-09 ~20:00Z). Se coordinó primero: se avisó a las dos sesiones `hammer-*` y `hammer-9f`
      contestó «vía libre», con los locks comprobados libres y sin builds en vuelo.