gitea 1.27.0 con sqlite y bindata: el binario sellado no podía abrir la base de datos

La mudanza de gioser pasa por levantar su gitea del otro lado — 28 repos, 26 sin copia fuera. El
corpus ya tenía `gitea` sellado (1.26.4, `b3:35bb4f04…`) y NO sirve, medido contra el artefacto:

    $ gitea --config app.ini migrate
    Error: sqlite3 requires: -tags sqlite,sqlite_unlock_notify
    this Gitea binary was not built with SQLite3 support

Construía, reproducía y no podía abrir la sqlite en la que gioser guarda TODO (`DB_TYPE = sqlite3`).
Y `gitea --version` decía `version development`. Es subcomando-sin-driver un piso más abajo.

Tres cambios, y el tercero es el que no se ve venir:

· Pin 1.27.0 (gioser corre 1.27.0). No es cosmético: gitea migra el esquema hacia adelante y se
  planta si la DB trae migraciones más nuevas que el binario, así que el pin va por delante del
  origen, nunca por detrás.
· Tags `sqlite,sqlite_unlock_notify` (⇒ `cgo = true`, el driver de mattn es C) y `bindata`, que
  embebe `public/` y `templates/`: sin él la receta publica sólo el ejecutable y el servidor
  arrancaría sin UI.
· La fuente pasa de `repo`+`commit` al TARBALL DE RELEASE. El clon no alcanza: la UI se compila
  con Node y las deps Go no están vendoreadas en git. El `gitea-src-1.27.0.tar.gz` trae las dos
  cosas hechas — medido: `public/assets/` 764, `vendor/` 11246, `templates/` 663 — así que
  construye con el lab tal cual, sin Node y sin red. La URL es locator (ADR 0013); ancla el sha256.

Nuevo hash: `b3:391a613e…`. Declarado en `perfil.servidor` como paquete y NO en `servicios`:
arrancarlo necesita el [[service]] del SDD 30 con su app.ini, y declarar un arranque que no existe
sería la mentira que ese campo existe para no tener.

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

docs/state/targets.toml

@@ -1287,6 +1287,14 @@ paquetes = [
   # dependencias — y es el mismo que ya sirve los 19 dominios de gioser, así que la migración no
   # cambia de servidor web además de cambiar de sistema.
   "caddy",
+  # `gitea` (2026-09-14): el servidor git que hoy corre en gioser y que la mudanza tiene que levantar
+  # del otro lado. Entra al perfil porque es el PASO 1 del plan de mudanza visto por el lado bueno:
+  # 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.
   # `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",

recipes/gitea.toml

@@ -1,21 +1,60 @@
-# Importada de nixpkgs por `takana import-nix` (Etapa G). PUNTO DE PARTIDA, no final:
-# - el build usa el lab de takana (zig-cc / musl estático), NO el stdenv de nix ⇒ revisá
-#   compiler/link/phases y adaptá hasta que compile.
-# - las deps van con su nombre NIX; remapealas a las recetas del corpus si difieren.
+# gitea — el servidor git que hoy corre en gioser y que la mudanza tiene que levantar del otro lado.
+#
+# ══ POR QUÉ EL TARBALL DE RELEASE Y NO `repo` + `commit` ═══════════════════════════════════════
+# El clon del repo NO alcanza para construir un gitea que sirva: la UI se compila con Node
+# (`make frontend` ⇒ `public/assets/`) y las deps Go no están vendoreadas en git. El tarball
+# `gitea-src-<ver>.tar.gz` que publica upstream trae las dos cosas ya hechas — medido sobre el de
+# 1.27.0: `public/assets/` 764 entradas, `vendor/` 11246, `templates/` 663 — así que se construye
+# con el lab tal cual, sin Node y sin red (`GOFLAGS=-mod=vendor GOPROXY=off`). Es también lo que
+# hacen Alpine y nixpkgs. La URL es locator y no entra en `hash_inputs` (ADR 0013): lo que ancla
+# la identidad es el `sha256`.
+#
+# ══ LOS TRES TAGS, Y POR QUÉ SIN ELLOS EL BINARIO SELLA Y NO SIRVE ═════════════════════════════
+# La receta anterior (1.26.4, sin tags, CGO off) producía un gitea que construye, reproduce y
+# **no puede abrir la base de datos**. Medido contra el binario sellado `b3:35bb4f04…`:
+#
+#     $ gitea --config app.ini migrate
+#     Error: sqlite3 requires: -tags sqlite,sqlite_unlock_notify
+#     this Gitea binary was not built with SQLite3 support
+#
+# y `gitea --version` decía `version development` (sin el `-X main.Version`). gioser guarda sus 28
+# repos con `DB_TYPE = sqlite3`, así que ese artefacto no sirve para la mudanza: es
+# [[subcomando-sin-driver]] otra vez — sellado, con contenido, reproducible e inútil.
+#
+#   · `sqlite` + `sqlite_unlock_notify` → el driver de mattn, que es C ⇒ obliga a `cgo = true`.
+#   · `bindata`                         → embebe `public/` y `templates/` en el binario. Sin él el
+#                                         servidor los busca en disco y la receta sólo publica el
+#                                         ejecutable: arrancaría sin UI.
+#
+# ⚠ La versión se PASA por `-ldflags -X`: no se deduce del árbol. Y no es cosmética — gitea migra
+# el esquema hacia adelante al arrancar y se planta si la DB trae migraciones más nuevas que el
+# binario, así que el pin tiene que ir por delante del que corre en el origen (gioser: 1.27.0).
 name    = "gitea"
-version = "1.26.4"
+version = "1.27.0"
 license = "MIT"
 
 [source]
-repo   = "https://github.com/go-gitea/gitea"
-commit = "95ba37d9af58db7d9163f9e92e07b5eb4f792bbc"
+tarball = "https://github.com/go-gitea/gitea/releases/download/v1.27.0/gitea-src-1.27.0.tar.gz"
+sha256  = "012df875bfa7764ade92301ac5e4225fc2c2aab7b3b40b4d6e7149a926253496"
 
 [build]
 compiler = "zig-cc"
 target   = "x86_64-linux-musl"
 link     = "static"
 flags    = []
+cgo      = true   # driver sqlite3 (mattn) con C bundled — necesita cgo, igual que usql/sq
 
-# buildInputs de nix (no usados con CGO off): go
 [deps]
 build = ["go"]
+
+[build.phases]
+configure = "true"
+compile   = """
+export GOCACHE=/src/.gocache GOTMPDIR=/src/.gotmp GOPATH=/tmp/gopath GOTOOLCHAIN=local \
+  CGO_ENABLED=1 CC="zig cc" CXX="zig c++" GOFLAGS=-mod=vendor GOPROXY=off
+mkdir -p /src/.gotmp /out/usr/bin
+go build -trimpath -tags 'bindata sqlite sqlite_unlock_notify' \
+  -ldflags '-buildid= -linkmode=external -extldflags=-static -X "main.Version=1.27.0" -X "main.Tags=bindata sqlite sqlite_unlock_notify"' \
+  -o /out/usr/bin/gitea .
+"""
+install   = "true"