boot entry survey: el informe del terreno, leyendo la ESP SIN montarla (ADR 0018 §4)

Reporta firmware, discos, ESPs, con quién se comparten y si la
instalación entra. No escribe nada — y para poder prometer eso hubo que
leer la ESP sin montarla, que es lo que obligó al lector FAT de sólo
lectura (fat_ro.rs). Montar para averiguarlo pedía privilegios, dejaba
un efecto secundario justo cuando prometimos no tocar nada, y falla si
el vecino dejó la FAT sucia por su hibernación.

Sobre una ESP de fábrica (100 MiB) con Windows dentro:

  FAT32 «ESP» — 100.0 MiB totales, 77.1 MiB usados, 22.1 MiB libres
  vecinos en \EFI: Microsoft, BOOT
    ⚠ «Microsoft» ⇒ hay Windows en esta ESP. Es el que reordena
      BootOrder al actualizarse.
  ✗ NO ENTRA: hacen falta 31.0 MiB y hay 22.1 MiB libres

Contrastado contra mtools como oráculo, que es lo que hace creíble el
número: mdir dice "23 221 248 bytes free" y el lector propio dice
22.1 MiB — el mismo. Los clusters libres se cuentan recorriendo la FAT y
NO se lee el FSInfo de FAT32 a propósito: ese campo lo deja
desactualizado un SO que desmontó mal, y un número optimista de más
haría fallar la instalación a mitad — justo lo que el §4 evita.

En el instalador el §4 resultó ser algo más que "cuánto espacio hay": la
rama UEFI se lleva el disco ENTERO, así que lo que hay que decir en voz
alta es con qué se lo va a llevar puesto. El survey corre antes de
particionar y nombra el \EFI\Microsoft si está. El usuario se entera
ANTES, y no después de que su Windows dejó de arrancar.

Dos cosas que habrían pasado inadvertidas sin test: el nombre largo
tiene que ganarle al 8.3 (sin juntar los LFN, "Microsoft" se lee
"MICROS~1" y la advertencia no dispara nunca), y el tipo de FAT sale del
número de clusters y no del texto del BPB, que es informativo y hay
formateadores que mienten. El primer test del tipo lo escribí mal —1999
clusters ES FAT12— y el síntoma es idéntico a un bug del lector.

78/78 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,7 @@
 # ADR 0018 — Soberanía del arranque: convivir con otro gestor sin depender de su buena fe
 
-- **Estado:** PROPUESTO, con **§1 y §3 IMPLEMENTADOS y verificados en OVMF** (2026-09-11).
-  Queda **una decisión abierta** (§Secure Boot) y el §2/§4 por implementar.
+- **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.
 - **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.
@@ -188,6 +188,44 @@ Un fallo silencioso concreto que muerde mucho: **las ESP de fábrica son de 100
 llena, y un bzImage con EFI-stub más su initramfs **no entra**. Eso tiene que fallar **ruidosamente
 y por adelantado**, con el número medido en pantalla — nunca truncar a mitad de instalación.
 
+> **ENMIENDA 2026-09-11 (4ª) — el §4 implementado: `takana boot entry survey`.**
+>
+> Reporta firmware, discos, ESPs, con quién se comparten y si la instalación entra. **No escribe
+> nada** — y para poder prometer eso hubo que leer la ESP **sin montarla**, que es lo que obligó a
+> escribir un lector FAT de sólo lectura (`crates/takana-cli/src/fat_ro.rs`). Montar para averiguarlo
+> tenía tres problemas: pide privilegios, deja un efecto secundario justo cuando prometimos no tocar
+> nada, y falla si el vecino dejó la FAT sucia por su hibernación (el «Fast Startup» del §7).
+>
+> Sobre una ESP de fábrica (100 MiB) con Windows dentro y el kernel duplicado a instalar:
+>
+> ```
+>   FAT32 «ESP» — 100.0 MiB totales, 77.1 MiB usados, 22.1 MiB libres
+>   vecinos en \EFI: Microsoft, BOOT
+>     ⚠ «Microsoft» ⇒ hay Windows en esta ESP. Es el que reordena BootOrder al actualizarse.
+>   ✗ NO ENTRA: hacen falta 31.0 MiB y hay 22.1 MiB libres
+>   ── veredicto ──
+>   ✗ …p1: faltan 8.9 MiB en la ESP
+> ```
+>
+> **Contrastado contra `mtools` como oráculo**, que es lo que hace que el número sea creíble: `mdir`
+> reporta `23 221 248 bytes free` y el lector propio dice 22,1 MiB — el mismo número. Los clusters
+> libres se cuentan recorriendo la FAT y **no** se lee el `FSInfo` de FAT32 a propósito: ese campo es
+> una pista que un sistema operativo que desmontó mal deja desactualizada, y un número optimista de
+> más haría fallar la instalación a mitad, que es exactamente lo que este §4 existe para evitar.
+>
+> **Y en el instalador el §4 resultó ser algo más que «cuánto espacio hay».** La rama UEFI se lleva
+> el disco **entero** (§Lo medido), así que lo que hay que decir en voz alta es **con qué se lo va a
+> llevar puesto**: el survey corre antes de particionar y, si hay un `\EFI\Microsoft` en ese disco,
+> lo nombra. El usuario se entera **antes**, y no después de que su Windows dejó de arrancar.
+>
+> Dos detalles que habrían pasado inadvertidos sin un test:
+> - **El nombre largo tiene que ganarle al 8.3.** Sin juntar los LFN, `Microsoft` se lee `MICROS~1` y
+>   la advertencia —la razón de ser de esto— no dispara nunca.
+> - **El tipo de FAT sale del número de clusters, no del texto del BPB**, que es informativo y hay
+>   formateadores que mienten en él. (El primer test que escribí para esto estaba mal calculado:
+>   1999 clusters *es* FAT12. El que fallaba era el test, y el síntoma es idéntico a un bug del
+>   lector.)
+
 ### 5. Respaldo del arranque como artefacto sellado
 
 Volcar NVRAM (`efibootmgr -v`) + el contenido de la ESP al store en cada instalación y cada