gitea arranca: su [[service]], probado con el entorno de verdad — y dos fallos que sólo salen ahí

La receta ya declara su servicio (SDD 30) y `perfil.servidor` lo habilita. El ArtifactHash NO se
mueve (`b3:391a613e…` antes y después): `[[service]]` está fuera de `hash_inputs`.

⚠ Primero, una corrección del commit anterior: declaraba `gitea` en `perfil.servidor` con SEIS
LÍNEAS DE COMENTARIO y sin la línea `"gitea",`. El perfil cargó igual, el grafo no dijo nada y el
paquete simplemente no estaba. Lo cazó `targets.py --services` al resolver el label: «lo declara
gitea, que NO pertenece al perfil». Un comentario que explica una entrada que no existe se lee como
la entrada.

La card no encarna el binario directo: **gitea se niega a correr como root** (`[F] Gitea is not
supposed to be run as root`), así que va por `setuidgid`. Y comprueba dos cosas del SITIO antes de
arrancar, saliendo 78 con un mensaje que las nombra: `/etc/gitea/app.ini` y el usuario `gitea`. Un
gitea sin config no falla — arranca y ofrece el asistente de «crear administrador» a quien pase.

Probado en el worker con el argv exacto y `env -i`, que es lo que arje hace de verdad. Tres fallos
que con una shell normal no se ven NUNCA:

· `exec setuidgid …` a secas ⇒ `sh: exec: line 0: setuidgid: not found`. El `sh` de busybox de la
  imagen no trae `FEATURE_SH_STANDALONE`: no despacha sus applets, los busca en `PATH`, y PID 1 no
  garantiza ninguno. Todo con ruta absoluta (`/bin/grep`, `/usr/bin/setuidgid`).
· sin `PATH` en el `envp` ⇒ `git not found: executable file not found in $PATH`. **gitea lanza
  `git` como subproceso**, y el mensaje se lee como «falta git» con git instalado y raíz de `base`.
  Un envp vacío no es «limpio»: es sin PATH.
· sin `cd` ⇒ `fatal: error reading '/root/.git'`. El cwd se hereda y gitea corre `git config` en él.
  `Service` no tiene campo `cwd`, así que va en el argv, a la vista.

Con eso: escucha, `GET /` responde **200** y el proceso corre como `gitea`. Las dos guardas
verificadas por separado (78 y su mensaje cada una). El worker quedó limpio y censado: sin usuario,
sin /etc/gitea, sin /var/lib/gitea, sin symlinks y sin procesos.

Y `/etc/gitea` entra en las rutas de la mudanza: el `app.ini` guarda los SECRETOS generados (gitea
los escribe en el propio fichero, que por eso tiene que ser suyo, `gitea:gitea 0660`).

⚠ Lo que queda abierto y está anotado en la receta: **el usuario `gitea` no existe en el producto**.
`/etc/passwd` de la imagen es la constante `takana_bootstrap::PRODUCT_PASSWD` y sólo trae `root` y
`sshd`. El SDD 30 sacó las Cards de una constante de Rust y las puso en la receta; los USUARIOS
siguen donde estaban las Cards. Hasta que se declaren, el usuario llega con los datos del sitio.

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

docs/state/targets.toml

@@ -1292,9 +1292,8 @@ paquetes = [
   # los 26 repos que sólo existen en la máquina que se borra dejan de estar solos en cuanto su origen
   # vive acá. Sus datos son 2,0 G de ficheros y una sqlite (`DB_TYPE = sqlite3`), así que mudarlos es
   # copiar un directorio — lo que NO es trivial es el binario, ver el encabezado de `recipes/gitea.toml`.
-  # ⚠ Declarado como PAQUETE, todavía no en `servicios`: para arrancarlo hace falta el `[[service]]`
-  # del SDD 30 con su `app.ini`, su usuario y su ruta de datos. Instalado y sin levantar es honesto;
-  # ponerlo en `servicios` sin la Card sería declarar un arranque que no existe.
+  # Su `[[service]]` está en la receta y el perfil lo arranca (abajo, en `servicios`).
+  "gitea",
   # `curl`/`wget`: bajar del mirror y del repo. `takana install --repo https://…` los necesita del
   # lado del cliente, y son también la única forma de diagnosticar un origen caído desde la caja.
   "curl", "wget",
@@ -1346,4 +1345,9 @@ paquetes = [
 # Es la versión servicios de la lección de `foot` — la métrica mide la clausura de lo declarado y no
 # puede ver lo que falta en la declaración. Comprobado antes de escribir esta línea: el resolutor
 # avisaba «`openssh` está en la imagen y TRAE este servicio, pero el perfil no lo arranca».
-servicios = ["sshd"]
+# `gitea` (2026-09-14): el servidor git de la mudanza. Se habilita acá y el CÓMO lo dice su receta.
+# ⚠ Su card comprueba dos cosas del SITIO antes de encarnar —`/etc/gitea/app.ini` y el usuario
+# `gitea` en `/etc/passwd`— y sale con 78 si falta alguna. Es a propósito: las dos vienen con los
+# datos de la mudanza, y un gitea que arranca sin su config ofrece el asistente de «crear
+# administrador» a quien pase. Hasta que la mudanza traiga ambas, este servicio NO levanta y lo dice.
+servicios = ["sshd", "gitea"]