perfil.servidor: fuera el prebuilt ajeno, entra el toolchain propio

Sale `rust-toolchain-bin` —799 M de bytes AJENOS sellados tal cual (`foreign`)—, que era el escalón 1
del SDD 31 y cumplió su función: con él se construyó el escalón 2, y el escalón 2 ya compila,
enlaza y corre.

Entran TRES, que son el mismo hecho («esta caja compila Rust») partido en piezas:
· `rust` (353 M) — el compilador y cargo, de la granja, desde fuente.
· `lld21` — el enlazador. NO es opcional: una caja takana no tiene `cc`, y sin enlazador `rustc`
  compila objetos y no produce un ejecutable.
· `cargo-config` — receta nueva que publica `/etc/cargo/config.toml` con las tres flags que unen a
  los dos. Sin ellas `cargo build` muere con «linker `cc` not found»: el toolchain estaría completo
  y MUDO, que es [[subcomando-sin-driver]] otra vez. Es config de SISTEMA y no de usuario a
  propósito — un `~/.cargo/config.toml` funcionaría para quien lo escribió y no para el siguiente.

⚠ Y `rust` se re-hashea otra vez (702094a8 → fe277b32) por una línea que descubrió el control de
PATH: **x.py instala en `/usr/local` por defecto, y el PATH de una caja takana es
`/bin:/usr/bin:/sbin:/usr/sbin`** — medido en la caja. O sea que el perfil habría proyectado un
`rustc` perfecto que nadie puede invocar: «existe ≠ se encuentra». Ahora `[install] prefix = "/usr"`,
como el resto del corpus.

Control previo que sí pasó: `rustc` y `cargo` corren SIN `LD_LIBRARY_PATH` — su `RUNPATH` es
`$ORIGIN/../lib`, así que la proyección del artefacto basta.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/state/targets.toml

@@ -1352,13 +1352,23 @@ paquetes = [
   # Su config (el `squid.conf`, el `passwd` y las dos ACL) es dato del SITIO y viaja con la mudanza,
   # no con el paquete: el servicio arranca sólo si está, y si no sale 78 diciéndolo.
   "squid",
-  # `rust-toolchain-bin` (2026-09-14): el compilador de Rust. Va en `servidor` y NO en `base` por
-  # tamaño —799 M— y porque una imagen de escritorio no compila nada; la caja que sirve el repo y
-  # construye sí. Es el paso 1 de tres: prebuilt ajeno (`foreign`) para desbloquear hoy; luego rustc
-  # desde fuente con el `llvm18` ya sellado; luego la cadena mrustc del selfhost. Sin compilador de
-  # Rust, la distro depende del LAB —un rootfs ajeno que ENTRA en el ArtifactHash— para poder
-  # reconstruir su propio instrumental, que son 12 crates y 42 555 líneas.
-  "rust-toolchain-bin",
+  # ── EL COMPILADOR DE RUST, QUE DESDE HOY ES NUESTRO (2026-09-16, SDD 31) ─────────────────────
+  # Acá vivía `rust-toolchain-bin`: el tarball oficial de rust-lang, 799 M de bytes AJENOS sellados
+  # tal cual (`foreign`). Era el escalón 1 —desbloquear hoy— y cumplió: con él se construyó el
+  # escalón 2, y el escalón 2 ya compila, enlaza y corre. Sale del perfil.
+  #
+  # Los tres que entran son el mismo hecho —«esta caja compila Rust»— partido en tres piezas:
+  #   · `rust`         el compilador y cargo, construidos por la granja desde fuente (353 M).
+  #   · `lld21`        el enlazador. NO es opcional: una caja takana **no tiene `cc`**, y sin
+  #                    enlazador `rustc` compila objetos y no produce un ejecutable.
+  #   · `cargo-config` las tres flags que unen a los dos (`/etc/cargo/config.toml`). Sin ellas,
+  #                    `cargo build` muere con `linker \`cc\` not found` — el toolchain estaría
+  #                    completo y mudo.
+  #
+  # ⚠ Va en `servidor` y NO en `base` por tamaño y por sentido: una imagen de escritorio no compila
+  # nada; la caja que sirve el repo y construye, sí. Y sigue siendo el paso 2 de tres: el 3 es la
+  # cadena mrustc del selfhost, que es lo único que quita la dependencia del LAB para arrancar.
+  "rust", "lld21", "cargo-config",
   # `netup` (2026-09-10): el cliente DHCP propio que levanta la red al arrancar. Entra como RAÍZ
   # aunque su binario YA venga dentro del `product-rootfs`, y por una razón concreta: el del producto
   # está congelado en el artefacto sellado del bootstrap, así que un arreglo de netup no llega nunca