feat(rp1): la cadena corre en la Pi 5 de la casa — binario aarch64, despliegue sin root y medida continua

David, 24-oct: «lo que podamos hacer en la rp1 hagamoslo no esperemos la VPS porfavor». Y ese
mismo día, por Ergon: la rp1 aloja el servidor de arranque de la red.

scripts/rp1/:
- construir-aarch64.sh + Dockerfile.aarch64: origin-chain-node release, con el WASM real, para
  linux/aarch64 en el Mac.
  - Imagen bookworm (glibc 2.36; la rp1 tiene 2.41).
  - Target en un volumen de Docker: la VM no ve el disco externo de compilación si se montó
    después de arrancar Docker, y reiniciarla tiraría los contenedores de otras hermanas.
  - Copia el binario con docker cp y avisa de cómo borrar el volumen.
- desplegar.sh: copia el binario con su sha256 (y deja el anterior para volver atrás), copia
  arrancar.sh y medir.sh, e instala tres líneas en el crontab del usuario: @reboot, vigilante
  cada 5 min y medida cada 5 min. Sin root y sin systemd.
- arrancar.sh: idempotente.
  - taskset -c 0-2: el nodo nunca toca el núcleo 3, el santuario de origin-banco de Laurha.
  - nice 10 + ionice 7: la CI de la casa va primero.
  - RPC sólo en 127.0.0.1; P2P en el 30333.
  - Cadena dev con Alice: es la testnet de la casa, con llaves públicas de desarrollo; ningún
    valor real.
- medir.sh: una fila CSV cada 5 min con best, finalizado, pares, RSS, CPU, MB de datos, load,
  temperatura y estado de la CI.

scripts/bench/max-de-n.py: funde N weights.rs del mismo pallet cobrando el MÁXIMO de cada
coeficiente.
- Por qué: Laurha midió el 24-oct en su santuario que 8 procesos idénticos de frame-omni-bencher
  separan el base weight hasta un 66 %.
- Se niega si los esqueletos difieren (otra lista de extrinsics o de storage) o si los conteos
  de reads/writes no coinciden. Avisa si N < 5.
- Controles: tres copias idénticas salen idénticas byte a byte; el máximo cae sólo donde se
  subió; un conteo de reads distinto se rechaza; un extrinsic renombrado se rechaza.

firmar_como_wallet: modo cuenta "<frase>" [//derivación], que da la llave sr25519 y la SS58 que
verá un wallet Substrate. Son los vectores para la migración de la wallet Origin! (Irhis).

fix(node): build-spec emite el chain spec REAL cuando el binario lleva el WASM.
- Antes, aunque el binario llevara el WASM real, emitía siempre el de mayo, con :code = «0x»
  simulado, y --raw no sacaba el génesis en crudo.
- Ahora usa el mismo spec con el que arranca run (node_chain_spec), y --raw lleva el génesis
  entero.
- Sin WASM sigue el simulado, pero avisa de que no sirve para unirse a una red. Mainnet sigue
  cerrada por la compuerta L-3.
- Por qué importa, medido hoy: el WASM del runtime NO es reproducible entre máquinas. El mismo
  commit compilado en el Mac y en Linux da génesis distintos (0xe80c… frente a 0x0926…), y el
  nodo del Mac baneó al de la rp1 con «Genesis mismatch». El génesis tiene que fijarlo un chain
  spec que se reparte, no quien compila.
- arrancar.sh usa ~/origin-chain/casa.json cuando existe (exportado en la propia rp1). Así un
  binario nuevo nunca crea otro génesis sobre los mismos datos.

Medido en vivo el 24-oct, todo por RPC firmado como un wallet:
- Nodo en la rp1 (Pi 5, Debian 13): bloques cada 6 s y finalidad a 2-3 bloques. RSS ~200 MB y
  afinidad 0-2 con nice 10.
- El vigilante de cron lo resucita con el mismo peer id
  (12D3KooWDWm5p3Z8Y5DddRki6M6nM1A2xUVQzPqNU1DW53uB6BVi) y sin regenerar la llave.
- E2E en la rp1: remark → ExtrinsicSuccess; finalize_override → ProposalNotFound; uphold0 →
  ZeroWeightWindowVote.
- casa.json exportado en la rp1 = estado del bloque 0 de la cadena viva: 46 de 46 claves
  idénticas. El nodo reinició sobre él con el mismo génesis y siguió desde el #155.
- Red de dos máquinas por la LAN: el nodo del Mac, con casa.json y la rp1 como bootnode,
  sincronizó (mismo best, mismo finalizado). Una transacción enviada al nodo del Mac la incluyó
  la rp1 en el bloque #167, con el mismo hash blake2-256 que devolvió author_submitExtrinsic.

Defectos encontrados en mis propios scripts antes de dejarlos publicados:
- desplegar.sh instalaba un crontab VACÍO: con set -e, el grep -v sobre un crontab vacío
  abortaba la subshell antes de los echo.
- medir.sh dejaba best/finalizado en NA: set -u con $2 sin definir, y stderr se iba con cron.
- max-de-n.py reescribía 16416 como 16_416 (la prueba de identidad lo cazó).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

scripts/rp1/construir-aarch64.sh

@@ -0,0 +1,38 @@
+#!/usr/bin/env bash
+# Compila origin-chain-node (release, con el WASM real) para la rp1, Raspberry Pi 5 linux/aarch64,
+# en un Mac Apple Silicon con Docker (linux/arm64 corre nativo, sin emulación).
+#
+#   scripts/rp1/construir-aarch64.sh <carpeta-destino-del-binario>
+#
+# Por qué así (medido el 2026-10-24):
+# - La rp1 no compila Substrate: es el runner de CI de la casa y tiene 8 GB.
+# - Imagen bookworm (glibc 2.36): el binario corre en la rp1 (Debian 13, glibc 2.41).
+# - El target vive en un VOLUMEN de Docker y no en el disco externo de compilación: la VM de
+#   Docker Desktop no ve /Volumes/MacOSBukup si el disco se montó después de arrancar Docker
+#   («not a directory»), y reiniciar Docker tiraría los contenedores de otras hermanas.
+#   Al acabar se copia el binario fuera y se borra el volumen.
+# - 4 jobs: la VM tiene 8 GB compartidos con las bases de datos de otras hermanas.
+# - WASM_BUILD_WORKSPACE_HINT=/src: substrate-wasm-builder busca Cargo.lock subiendo desde el
+#   target; con el target fuera del workspace no lo encuentra, resuelve dependencias nuevas
+#   (que piden rustc 1.90) y el build del runtime falla.
+set -euo pipefail
+DESTINO="${1:?carpeta destino}"
+RAIZ="$(cd "$(dirname "$0")/../.." && pwd)"
+IMG=origin-chain-builder:1.88-bookworm
+docker image inspect "$IMG" >/dev/null 2>&1 || docker build -q -t "$IMG" -f "$RAIZ/scripts/rp1/Dockerfile.aarch64" "$RAIZ/scripts/rp1"
+docker volume create charon-arm64-target >/dev/null
+docker volume create charon-arm64-registry >/dev/null
+docker run --rm --name charon-aarch64 \
+  -v "$RAIZ":/src:ro -v charon-arm64-target:/target -v charon-arm64-registry:/usr/local/cargo/registry \
+  -e CARGO_TARGET_DIR=/target -e WASM_BUILD_WORKSPACE_HINT=/src -e WASM_BUILD_STD=0 -e CARGO_BUILD_JOBS=4 \
+  -e CC_wasm32v1_none=clang -e AR_wasm32v1_none=llvm-ar \
+  -e CC_wasm32_unknown_unknown=clang -e AR_wasm32_unknown_unknown=llvm-ar \
+  -w /src "$IMG" cargo build --release -p origin-chain-node --features wasm-build
+mkdir -p "$DESTINO"
+# docker cp escribe desde el host: funciona aunque la VM no vea el destino (p. ej. /Volumes/…).
+C=$(docker create -v charon-arm64-target:/target "$IMG" true)
+docker cp "$C:/target/release/origin-chain-node" "$DESTINO/origin-chain-node"
+docker rm "$C" >/dev/null
+file "$DESTINO/origin-chain-node"
+shasum -a 256 "$DESTINO/origin-chain-node"
+echo "Para liberar el disco de Docker: docker volume rm charon-arm64-target charon-arm64-registry"