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

scripts/takana-live-install.sh

@@ -283,6 +283,17 @@ if [ -d /sys/firmware/efi ]; then
     echo "==> takana-install (UEFI): EFI-stub soberano en $DEV (ESP ${ESP_MB}M, root ${ROOT_MB}M, store ${STORE_MB}M, estado=resto)"
     echo "    ¡esto BORRA $DEV!"
 
+    # Informe del terreno ANTES de tocar nada (ADR 0018 §4). Esta rama se lleva el disco ENTERO, así
+    # que lo que hay que decir en voz alta no es sólo «cuánto espacio hay»: es **con qué se va a
+    # llevar puesto**. Si en la ESP de este disco hay un `\EFI\Microsoft`, el survey lo nombra, y el
+    # usuario se entera ANTES y no después de que su Windows dejó de arrancar.
+    #
+    # No escribe nada y no puede fallar el instalador: `|| true`. Su trabajo es informar.
+    if [ -x "$PAYLOAD/hammer" ]; then
+        echo "==> terreno actual de $DEV (nada de esto se ha tocado todavía):"
+        "$PAYLOAD/hammer" boot entry survey --disk "$DEV" 2>&1 | "$BB" sed 's/^/    /' || true
+    fi
+
     # MBR, 4 primarias: p1=ESP(0xEF) p2=root p3=store p4=estado. Sectores explícitos (como la rama BIOS).
     SPM=2048
     P1S=2048;            P1E=$(( P1S + ESP_MB  * SPM - 1 ))