SDD 30 §4b.2: la cadena entera probada en un arranque real — PRODUCT_SSH_OK

Los tests no eran el punto: el punto era que un servicio DECLARADO en una receta
termine supervisado por PID 1. `product-boot-test.sh` sobre el product-rootfs de
la ruta real da `ok card sshd en la seed` y `PRODUCT_SSH_OK uid=0`, sin ningún
eslabón escrito a mano:

  recipes/openssh.toml [[service]] → sidecar dentro del artefacto sellado →
  service_cards() → genesis de /ente/seed.card.json → arje-zero encarna sshd →
  la sesión SSH responde.

Y HABÍA QUE DESCARTAR QUE LO MOVIERA ESTE CAMBIO: el product-rootfs salió con
hash distinto (5011955a… → 8639894332…). No fue la seed — las dos son
BYTE-IDÉNTICAS (diff del JSON, cero diferencias). Cambiaron `netup`, que es otro
artefacto que cuando se selló el viejo, y por arrastre `ente/attest.json`, que
registra su BLAKE3. O sea: la constante y la receta producen la misma seed,
comprobado sobre el árbol real y no sólo en un test.

Y queda escrito por qué el ESCRITORIO no se puede arrancar supervisado todavía,
que es corpus y no diseño: gnome-shell en deuda (bloqueado sólo por
evolution-data-server, que tiene blocked_by vacío) y sway sin sellar. Sin
compositor no hay sesión. NO se cablearon los scripts de imagen a ciegas: inyectar
cards en un genesis que no se puede bootear es escribir código que nadie puede
contradecir, y este mismo doc ya tiene el ejemplo de qué pasa entonces (el SDD 06
afirmando meses un lector que no existía).

docs/30-servicios-de-paquete.md

@@ -1,6 +1,7 @@
 # SDD 30 — Los servicios que trae un paquete
 
-> **Estado:** §3, §4a y §4b IMPLEMENTADOS (2026-09-12/13), §4c y §5 abiertos. Nace de una pregunta directa:
+> **Estado:** §3, §4a y §4b IMPLEMENTADOS y **VALIDADOS EN ARRANQUE REAL** (2026-09-12/14);
+> §4c cerrado para la imagen de producto y bloqueado para las de escritorio; §5 abierto. Nace de una pregunta directa:
 > *«los paquetes que tienen sus servicios para systemd, openrc u otros, ¿ya saben empaquetarse en
 > takana con arje?»*. La respuesta medida era **no**, y este documento dice exactamente qué faltaba,
 > qué se cerró y qué queda.
@@ -182,6 +183,34 @@ Coste que conviene saber: los árboles ya hidratados compartían inodes con el a
 nuevo tiene inodes propios (`%h = 1`). El contenido es el mismo, pero hasta que esos árboles se
 refresquen el disco lleva dos copias.
 
+### 4b.2 La cadena entera, probada en un arranque real
+
+No alcanza con que los tests pasen: el punto de todo esto es que **un servicio declarado en una
+receta termine supervisado por PID 1**. Medido el 2026-09-14, `scripts/product-boot-test.sh` sobre
+el `product-rootfs` ensamblado por la ruta real:
+
+```
+   ok  card sshd en la seed
+   ==> boot QEMU (mem 2048), hostfwd :2223->:22
+   PRODUCT_SSH_OK uid=0
+```
+
+La cadena completa, sin ningún eslabón escrito a mano:
+
+    recipes/openssh.toml `[[service]]`
+      → sidecar `.hammer/recipe.toml` DENTRO del artefacto sellado
+        → `service_cards()` (scope = system)
+          → `genesis` de `/ente/seed.card.json`
+            → arje-zero encarna sshd al boot
+              → la sesión SSH responde
+
+**Y el hash no se movió por esto.** El `product-rootfs` salió con hash distinto al anterior
+(`5011955a…` → `8639894332…`), y había que saber si lo movía este cambio: **no**. La seed de ambos
+árboles es **byte-idéntica** (`diff` sobre el JSON: sin diferencias); lo que cambió fueron `netup`
+—otro artefacto que cuando se selló el viejo— y, por arrastre, `ente/attest.json`, que registra su
+BLAKE3. La constante y la receta producen exactamente la misma seed, comprobado sobre el árbol real
+y no sólo en un test.
+
 **(c) Los de GNOME: DECLARADOS, no todavía arrancados por arje.** Las nueve unidades que
 `gnome-start-qemu.sh` levanta con `&` están declaradas en sus recetas y habilitadas en el perfil
 (`dbus-system`, `logind-compat`, `polkit-compat`, `accounts-daemon`, `upowerd`, `colord` de sistema;
@@ -200,8 +229,26 @@ Dos cosas que NO son transcripción y hay que saber:
    a PID 1 por `RunCard`), pero mutter y kwin no tienen esa integración. `--services` avisa por cada
    una: el hueco queda contado, no omitido.
 
-Falta el paso final: que el ensamblado de la imagen ponga las cards de sistema en el `genesis` en vez
-de que el script las lance con `&`. Eso ya es §4b (el emisor) y el arranque supervisado en QEMU.
+#### Por qué el escritorio NO se puede arrancar supervisado todavía (medido)
+
+El paso final —que el ensamblado de la imagen ponga las cards de sistema en el `genesis` en vez de
+que el script las lance con `&`— **no está bloqueado por diseño sino por corpus**, y conviene que
+esté escrito para no volver a averiguarlo:
+
+| imagen | estado | qué falta |
+|---|---|---|
+| `escritorio-gnome` | 307/309 de la clausura sellada | **`gnome-shell` en deuda**, y su único bloqueante es `evolution-data-server` (que tiene `blocked_by: []` — o sea que sus deps ya están: falta construirlo, no destrabarlo) |
+| `escritorio-sway` | 260/261 | **`sway` mismo sin sellar** |
+
+Sin el compositor/shell no hay sesión que arrancar, así que el arranque supervisado de escritorio no
+es verificable hoy por más cards que se inyecten. Y el andamiaje de la imagen tampoco está: en este
+hub `work/metal-rootfs` no existe y `work/gnome-rootfs` son 388 K de residuo, no el cierre hidratado.
+
+**Lo que NO se hizo a propósito:** cablear los scripts de imagen a ciegas. Inyectar cards en un
+`genesis` que no se puede bootear es escribir código que nadie puede contradecir — y este documento
+ya tiene un ejemplo de lo que pasa entonces (el SDD 06 afirmando durante meses un lector que no
+existía). El mecanismo está probado donde SÍ se puede arrancar (§4b.2); el escritorio espera a que
+su corpus cierre.
 
 ## 5. El hueco que no es nuestro: no hay readiness
 
@@ -233,7 +280,8 @@ arriba en arje.
 | Los 9 de GNOME declarados y habilitados (hash sin mover, 9/9) | ✅ §4c |
 | Emisor desde el sidecar (`service_cards`, falla ruidosa + test) | ✅ §4b |
 | Re-sellado de openssh con control → **reproduce bit a bit** | ✅ §4b.1 |
-| Que la imagen los arranque por arje y no por el script `&` | ◻ §4c, depende de §4b |
+| La cadena receta→sidecar→card→genesis→arje, **en arranque real** | ✅ §4b.2 (`PRODUCT_SSH_OK`) |
+| Que la imagen de ESCRITORIO los arranque y no el script `&` | ⛔ §4c, bloqueado (abajo) |
 | `escritorio-cosmic`: auditar su `cosmic-start.sh` y habilitar | ◻ hoy sale con 5 AVISO |
 
 **La primera lectura del vigía**, para que no haya que creerle a este documento: 0 errores y 18