ADR 0016: corregida la afirmacion sobre el baseline del selfhost

Se afirmo que la etapa 4 invalidaba el baseline of_tree porque el nombre del
crate va en los simbolos de hammerd. El razonamiento era correcto y la
conclusion no: recipes/hammerd.toml pinea su fuente por COMMIT, no por el arbol
de trabajo, asi que el renombre no la alcanza.

Medido: los cuatro componentes de Stage 1 tienen vigente == sellado
(musl ce952f72, busybox 2a2b1280, hammerd 48bbbe52, arje-zero b34c571b).
No hay nada que rehacer por causa del renombre.

Queda anotado aparte que el of_tree del stage1 sellado hoy (d152f060) no
coincide con ninguna de las dos constantes del script. No se re-ancla: sin
correr el verify in-VM seria poner una constante que nadie verifico, y esta
maquina no tiene KVM.

docs/adr/0016-renombre-takana.md

@@ -123,10 +123,36 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con
      **ya instalados** y hornea un hook de arranque que lo invoca por ese nombre. Renombrarlo no
      rompe el repo: rompe máquinas instaladas.
 
-   **Consecuencia que hay que anotar igual:** al renombrar `hammer-core`, los bytes de `hammerd`
-   cambian de todos modos —linkea contra un crate con otro nombre y el nombre va en los símbolos—,
-   así que **el baseline `of_tree` del selfhost hay que rehacerlo**. Es efecto de la etapa 4, no de
-   un cambio en `hammerd`.
+   **Una consecuencia que se anotó y resultó FALSA — corregida el 2026-09-09.** Se afirmó que al
+   renombrar `hammer-core` los bytes de `hammerd` cambiaban —linkea contra un crate con otro nombre
+   y el nombre va en los símbolos— y que por eso **había que rehacer el baseline `of_tree` del
+   selfhost**. El razonamiento es correcto y la conclusión no, porque le faltaba un dato:
+
+   **`recipes/hammerd.toml` pinea su fuente por `commit`, no por el árbol de trabajo**
+   (`commit = "e9b0551213…"`). El renombre vive en el working tree; la receta construye desde un
+   commit congelado. El cambio no la alcanza.
+
+   Medido, receta por receta, con `takana hash` contra lo sellado:
+
+   | componente de Stage 1 | vigente | sellado |
+   |---|---|---|
+   | `musl` | `ce952f72` | `ce952f72` |
+   | `busybox` | `2a2b1280` | `2a2b1280` |
+   | `hammerd` | `48bbbe52` | `48bbbe52` |
+   | `arje-zero` | `b34c571b` | `b34c571b` |
+
+   ⇒ **Los cuatro idénticos: la etapa 4 no movió el baseline y no hay nada que rehacer por su
+   causa.** El baseline se moverá el día que alguien suba el `commit` de `recipes/hammerd.toml` a
+   uno que contenga los crates renombrados — que es una decisión aparte, no un efecto colateral.
+
+   **Lo que sí apareció al ir a mirar, y no es de esta campaña:** el `of_tree` del `stage1-rootfs`
+   sellado hoy en `./store` es `b3:d152f060…`, que **no coincide con ninguna de las dos constantes
+   del script**: `EXPECT_REF` = `9adefb82…` (toolchain Alpine) ni `RUST_EXPECT_REF` = `7fa6cb4e…`
+   (takana-rust). Puede ser deriva vieja o corresponder a otra configuración de store —los variantes
+   rust usan `store-rust`/`store-rust2`—; **con los datos que hay no se puede afirmar cuál**, y
+   re-anclar un número sin correr el verify in-VM que pruebe que reproduce sería poner una constante
+   que nadie verificó. Esta máquina **no tiene `/dev/kvm`** (4 cores, 7 GiB), así que ese verify no
+   se corre acá. Queda como su propia tarea, con su propia máquina.
 
 4 bis. **Variables de entorno: leen las dos, gana la nueva.** ← *hecho (2026-09-09)*.