sergio/takana

18 MB en la capa de quien vive en una terminal; por herencia llega a los
cuatro escritorios grandes y a servidor. `mandoc` ya viajaba en `base` con
`man`, `apropos` y `whatis`, así que el lector estaba puesto y sólo faltaba
qué leer.

Probado de punta a punta con el artefacto definitivo:

    man -M <artefacto>/usr/share/man open   ⇒ rc=0, renderiza open(2)
    man ... malloc                          ⇒ rc=0, renderiza malloc(3)

Funciona SIN índice porque el `man` de mandoc cae a buscar en el sistema de
ficheros cuando no hay `mandoc.db`.

⚠ Y lo que esto NO arregla, que conviene dejar escrito donde se mira: `apropos`,
`whatis` y `man -k` siguen devolviendo «nothing appropriate», y no es culpa de
este paquete. `makewhatis` crea el temporal `mandoc.db~` con contenido válido y
muere con SYSERR; al renombrarlo a mano, su propio lector dice:

    dbm_map(mandoc.db): Inconsistent file size 260 (expected 4)

Escritor y lector discrepan SIENDO EL MISMO BINARIO (makewhatis es un enlace
duro de mandoc que despacha por argv[0] — verificado: con otro nombre se
comporta como mandoc y dice «read: Is a directory»). La hipótesis es detección
de endianness cayendo al código de compatibilidad bajo musl/zig, pero NO leí su
configure: lo medido es la discrepancia, no la causa.

Es su propia unidad de trabajo porque mandoc vive en `base` y reconstruirlo
cascadea a todas las imágenes.

diff --git a/docs/state/targets.toml b/docs/state/targets.toml
index fb0fb9f0..b35cc4d6 100644
--- a/docs/state/targets.toml
+++ b/docs/state/targets.toml
@@ -384,6 +384,27 @@ paquetes = [
   # `escritorio-sway`. En las otras imágenes el resto de `pass` funciona y `-c` muere con un
   # mensaje claro, que es el comportamiento de upstream, no una avería nuestra.
   "pass", "qrencode",
+  # ── LA DOCUMENTACIÓN DEL SISTEMA (2026-10-21) ────────────────────────────────────────────────
+  # `man-pages` son 18 MB y 3.153 páginas, y cierran un hueco que el censo describía MAL. No era
+  # «no hay páginas de manual»: el store ya tenía 4.710 de sección 3 y 1.074 de la 1, porque cada
+  # paquete trae las suyas y `man pass` funciona desde siempre. Lo que faltaba era exacto:
+  #
+  #     find /store/*/usr/share/man/man2 -type f | wc -l   ⇒  0
+  #
+  # CERO llamadas al sistema documentadas en todo el corpus, más las funciones de libc y las
+  # páginas de concepto. `man open`, `man mmap`, `man malloc` y `man signal` no contestaban nada.
+  # Para una distro que se compila a sí misma desde fuente eso es un hueco con nombre.
+  #
+  # Va en `cli` porque es la capa de quien vive en una terminal, y por herencia llega a los cuatro
+  # escritorios grandes y a servidor. `mandoc` —que publica `man`, `apropos` y `whatis`— ya viaja
+  # en `base`, así que el lector estaba puesto y sólo faltaba qué leer.
+  #
+  # ⚠ Lo que esto NO arregla: `apropos` y `man -k` siguen sin funcionar, y no es culpa de este
+  # paquete. `makewhatis` (de mandoc, en /usr/sbin) muere al escribir el índice, y su lector dice
+  # `dbm_map(mandoc.db): Inconsistent file size 260 (expected 4)` — escritor y lector discrepan
+  # SIENDO EL MISMO BINARIO. Es un defecto del empaquetado de mandoc, con su propia unidad de
+  # trabajo: tocarlo reconstruye `base` y cascadea a todas las imágenes.
+  "man-pages",
   # ── SELLADAS DESDE HACE MESES Y EN NINGUNA IMAGEN (2026-09-12) ───────────────────────────────
   # editor, multiplexor, gestor de ficheros e historial de shell: las cuatro piezas con las que se
   # VIVE en una terminal. `helix` estaba declarada sólo en escritorio-gnome, que es donde menos