boot entry backup/restore: el arranque como estado reproducible (ADR 0018 §5)

Guarda las variables de NVRAM CRUDAS —se reescriben tal cual;
decodificarlas para volver a codificarlas al restaurar sería una
oportunidad de perder algo que no entendemos— y de la ESP un manifiesto
con hashes, no los bytes: el kernel ya vive en el store y copiarlo otra
vez sería churn. El manifiesto es evidencia de qué había; para lo que no
esté en el store dice qué falta, en vez de prometer reponerlo.

El ADR se equivocaba en DÓNDE: decía "volcar al store". No va al store,
porque lo barre store-gc.sh, que clasifica por nombre de receta — un
respaldo ahí sería huérfano y se borraría en el primer --huerfanos. Vive
en /var/lib/hammer/boot/, que en las imágenes es su propia partición. El
nombre sale del CONTENIDO, así que un arranque que no cambió produce el
mismo fichero: corre en cada arranque sin llenar la partición de copias.

Lo que encontró la prueba de punta a punta y no estaba en el diseño:
restaurar es volver al pasado, y lo que llegó DESPUÉS no estaba en ese
pasado. Al reponer el BootOrder del respaldo, el Windows instalado más
tarde quedaba FUERA del orden — correcto, y justo lo que el usuario no
espera de algo llamado "restaurar el arranque". Ahora se avisa antes,
con nombre y apellido, y restore NO escribe por defecto: la NVRAM es lo
único de la máquina que no se rehace desde el store.

El lector FAT ganó lectura de ficheros, con su trampa propia: hay que
truncar al tamaño DECLARADO en el directorio, no al final del último
cluster. Un fichero de 1,5 MB en clusters de 1 KiB termina con relleno y
hashear el relleno daría un hash distinto al del mismo fichero en disco
— el síntoma sería "dos respaldos del mismo arranque difieren".
Verificado contra mtools como oráculo (1 500 000 y 900 000 bytes
exactos, mismo sha256 que los originales) y con un test determinista que
fabrica una FAT16 a mano, sin depender de que mtools esté.

79/79 del CLI.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HHAKWoBqof9XvsYCvDicEj

docs/adr/0018-soberania-del-arranque.md

@@ -1,7 +1,8 @@
 # ADR 0018 — Soberanía del arranque: convivir con otro gestor sin depender de su buena fe
 
-- **Estado:** PROPUESTO, con **§1, §2, §3 y §4 IMPLEMENTADOS y verificados** (2026-09-11).
-  Queda **una decisión abierta** (§Secure Boot) y el §5 (respaldo del arranque) por implementar.
+- **Estado:** PROPUESTO, con **§1 a §5 IMPLEMENTADOS y verificados** (2026-09-11/12).
+  Queda **una decisión abierta** (§Secure Boot); el §6 es una no-acción deliberada y el §7 va al
+  manual del piloto (SDD 21).
 - **Fecha:** 2026-09-11
 - **Frontera:** `scripts/install-image-efi.sh`, `scripts/install-image.sh`, `scripts/iso-image.sh`,
   `scripts/metal-usb-sdboot.sh`, `scripts/takana-live-install.sh`, el instalador TUI.
@@ -232,6 +233,44 @@ Volcar NVRAM (`efibootmgr -v`) + el contenido de la ESP al store en cada instala
 actualización de arranque. «Restaurar el arranque» pasa de adivinar a **reproducir un estado
 conocido**. Barato, y es exactamente la forma de takana.
 
+> **ENMIENDA 2026-09-11 (5ª) — el §5 implementado, y el ADR se equivocaba en DÓNDE guardarlo.**
+>
+> `takana boot entry backup` / `restore`. El respaldo guarda las variables de NVRAM **crudas** —se
+> reescriben tal cual; decodificarlas para volver a codificarlas al restaurar sería una oportunidad
+> de perder algo que no entendemos— y de la ESP un **manifiesto con hashes**, no los bytes: el kernel
+> ya vive en el store y copiarlo otra vez sería churn. El manifiesto es **evidencia de qué había**;
+> para lo que no esté en el store dice qué falta, en vez de prometer que lo puede reponer.
+>
+> **Corrección al §5 tal como estaba escrito:** decía «volcar al store». **No va al store.** Lo barre
+> `store-gc.sh`, que clasifica por nombre de receta: un respaldo ahí sería *huérfano* y se borraría
+> en el primer `--huerfanos`. Vive en `/var/lib/hammer/boot/`, que en las imágenes es **su propia
+> partición** y sobrevive a una reinstalación del sistema. El nombre del fichero sale del
+> **contenido**, así que un arranque que no cambió produce el mismo fichero y esto puede correr en
+> cada arranque sin llenar la partición de estado con copias idénticas.
+>
+> **Lo que encontró la prueba de punta a punta, y que no estaba en el diseño:** restaurar es volver
+> al pasado, **y lo que llegó después no estaba en ese pasado**. Al reponer el `BootOrder` del
+> respaldo, el Windows instalado *más tarde* quedaba **fuera del orden** — semánticamente correcto y
+> exactamente lo que el usuario no espera de algo llamado «restaurar el arranque». Ahora se avisa
+> antes, con nombre y apellido:
+>
+> ```
+>   ⚠ ESTO SACA DE BootOrder a 1 entrada(s) que hoy sí están:
+>       Boot0001 «Windows Boot Manager»
+>     Son las que aparecieron DESPUÉS del respaldo. Si alguna es otro sistema
+>     operativo, va a dejar de arrancar desde el menú del firmware hasta que la repongas.
+> ```
+>
+> Y `restore` **no escribe por defecto**: hay que pasar `--apply`. La NVRAM es lo único de la máquina
+> que no se puede rehacer desde el store.
+>
+> El lector FAT ganó lectura de ficheros para el manifiesto, con su trampa propia: **hay que truncar
+> al tamaño declarado en el directorio**, no al final del último cluster. Un fichero de 1,5 MB en
+> clusters de 1 KiB termina con relleno, y hashear el relleno daría un hash distinto al del mismo
+> fichero en disco — el síntoma sería «dos respaldos del mismo arranque difieren». Verificado contra
+> `mtools` como oráculo (extrae 1 500 000 y 900 000 bytes exactos, mismo sha256 que los originales) y
+> con un test determinista que fabrica una FAT16 a mano, sin depender de que mtools esté.
+
 ### 6. Lo que takana NO hace: `os-prober`
 
 No se escanean discos ajenos para adivinar qué sistemas hay y generar entradas. Es una fuente