recetas: takana se empaqueta a sí mismo — y el alias del ADR 0016 volvía al crate INEMPAQUETABLE

El corpus construía 869 recetas y no la suya. `takana` sólo existía como `cargo build --release`
sobre un clon del repo, y eso bloqueaba lo de arriba de todo del SDD 28: que un servidor takana se
sirva sus propios paquetes **a su propio host**. El host necesita `takana` instalado para consumir
el repo, y no podía instalarlo DESDE el repo porque no estaba en el repo.

**El muro, que nadie había tocado porque takana nunca se había empaquetado:** `takana-cli` declara
DOS `[[bin]]` sobre el mismo `main.rs` (`takana` y `hammer`, la compatibilidad de la etapa 2 del
ADR 0016). El camino Cargo del corpus invoca `cargo rustc … -- -C target-feature=+crt-static`, y
`cargo rustc` con argumentos extra **sólo admite UN target**:

    error: extra arguments to `rustc` can only be passed to one target, consider filtering
           the package by passing, e.g., `--lib` or `--bin NAME` to specify a single target

O sea: la decisión de emitir dos binarios —tomada para que el alias sobreviviera a `cargo clean` y a
la siembra de la granja, que excluye `/target`— hacía que el crate no se pudiera empaquetar. Se
resuelve con `--bin takana` y reponiendo `hammer` como ENLACE en la fase de instalación: en el árbol
de build un symlink no sobrevive, pero en el ARTEFACTO sellado es permanente y no duplica los megas.

Y ese alias tapa un agujero real: **`arje-zero` todavía invoca el binario por el nombre viejo** — en
el primer arranque de la caja de producción se leyó `hammer no corre, sin menú de arranque`. Viene
pineado desde tawasuyu, así que no se arregla desde este repo; mientras `hammer` esté en el
artefacto, el menú de arranque por grafo del ADR 0010 tiene qué ejecutar. Cuando la etapa 6 retire
el alias, hay que subir arje-zero ANTES.

Sellado `b3:941d1857…`, 3,3 M con el split de debug. Verificado: ELF estático, `takana --version` y
`hammer --version` dan los dos `takana 0.0.1`.

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

recipes/takana.toml

@@ -0,0 +1,54 @@
+# takana — EL BINARIO DEL PROYECTO, empaquetado como una receta más del corpus.
+#
+# POR QUÉ EXISTE (SDD 28 §3.4). El corpus construía 869 recetas y no la suya: `takana` sólo existía
+# como `cargo build --release` sobre un clon del repo. Eso bloqueaba lo de arriba de todo — que un
+# servidor takana **se sirva sus propios paquetes a su propio host**: el host necesita `takana`
+# instalado para consumir el repo, y no podía instalarlo DESDE el repo porque no estaba en el repo.
+#
+# Receta Cargo, mismo patrón que `hammerd`/`netup`/`arje-zero`: crate del workspace takana a un
+# commit fijado (ADR 0006), deps vendoreadas en el fetch para un build hermético `--offline`, enlace
+# estático con `zig cc`. Sin dependencias C: el CLI es Rust puro (clap/serde/toml/nix/tracing).
+#
+# ⚠ EL ALIAS DEL ADR 0016 VOLVÍA AL CRATE INEMPAQUETABLE, y se descubrió acá porque takana nunca se
+# había empaquetado. `takana-cli` declara DOS `[[bin]]` sobre el mismo `main.rs` (`takana` y `hammer`,
+# la compatibilidad de la etapa 2). El camino Cargo del corpus invoca `cargo rustc … -- -C
+# target-feature=+crt-static`, y **`cargo rustc` con argumentos extra sólo admite UN target**:
+#
+#     error: extra arguments to `rustc` can only be passed to one target, consider filtering
+#            the package by passing, e.g., `--lib` or `--bin NAME` to specify a single target
+#
+# Por eso `--bin takana` en los flags. Y `hammer` se repone en la fase de instalación como ENLACE, no
+# como segundo binario: en el ÁRBOL DE BUILD un symlink no sobrevive (`cargo clean` lo borra y la
+# siembra de la granja excluye `/target` — por eso el ADR eligió dos `[[bin]]`), pero en el ARTEFACTO
+# sellado es permanente y no duplica los megas.
+#
+# Que `hammer` esté en el artefacto TAPA además un agujero real: `arje-zero` todavía invoca el binario
+# por el nombre viejo — en el primer arranque de la caja de producción se leyó `hammer no corre, sin
+# menú de arranque` — y viene pineado desde tawasuyu, así que no se arregla desde este repo. Cuando la
+# etapa 6 retire el alias, hay que subir arje-zero ANTES.
+
+name    = "takana"
+version = "0.0.1"
+license = "MIT"
+
+[source]
+# El repo del propio takana: el `commit` es el identificador inmutable; la URL es sólo locator y no
+# entra en `hash_inputs` (ADR 0013 §1). Subirlo cuando el CLI avance.
+repo   = "ssh://gitea@git.gioser.net:2345/sergio/takana.git"
+commit = "3ff7585aa251913acad6fd26d9142da408bd02f9"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "static"
+
+# Split de la info de depuración (SDD 23 etapa 4). Entra en `hash_inputs`.
+strip_debug = true
+flags    = ["-p", "takana-cli", "--bin", "takana"]
+
+[build.phases]
+# Sobrescribe el `find target/release …` por defecto: hay que reponer el alias `hammer` (ver arriba).
+install = "mkdir -p /out/usr/bin && cp target/release/takana /out/usr/bin/takana && ln -s takana /out/usr/bin/hammer"
+
+[deps]
+build = ["binutils"]