feat(weights): RV13 — los 19 estaban subdeclarados, los 19

Primera medicion real de los weights con frame-omni-bencher sobre el
propio blob WASM. El resultado no es un ajuste fino: los 19 extrinsics
de los 5 pallets custom declaraban MENOS de lo que cuestan.

EL PATRON SISTEMATICO. Se costeo el storage del pallet y se olvido el
que cuesta emitir un evento — System::Events, EventCount, ExecutionPhase
y Number son reads y writes reales en cada extrinsic que deposita
evento. Ejemplos medidos: attest_asset declaraba 4 reads / 1 write y
cuesta 7/3; submit_proposal declaraba 12 us y cuesta 62; register_agent_did
declaraba 3/2 y cuesta 6/4.

EL PEOR, Y ES UN ERROR MIO DOCUMENTADO AL REVES. proof_size valia 0 en
los 19. La cabecera de los interinos afirmaba que T::DbWeight "puebla
tanto ref_time como proof_size ... cerrando el hueco". Es falso y se
comprueba en la fuente: sp_weights::RuntimeDbWeight solo tiene los
campos read y write, y reads(r) devuelve from_parts(read * r, 0). Los
interinos arreglaron reads/writes y dejaron el proof_size exactamente
donde estaba. Un proof_size en cero miente al block-builder sobre el
peso PoV: es el vector de DoS que la nota decia haber cerrado. La
afirmacion sobrevivio mas de un mes sin que ninguna lectura la
desmintiera; la desmintio una medicion.

Cada fichero generado lleva ahora un guard GENERADO desde la lista real
de benchmarks que reprueba cualquier proof_size = 0 o ref_time = 0.
Verificado que sabe reprobar: contra los weights anteriores se pone rojo
con "`attest_asset` declara proof_size = 0".

ADVERTENCIA QUE VA EN EL CODIGO, NO SOLO AQUI: son numeros de un
MacBook Pro M3 Max, NO del banco de referencia BM V2. La forma
(reads/writes/proof_size) no depende del hardware y es correcta; el
ref_time si, y en un Pi 5 sera mayor. Un caso lo enseña solo:
attest_asset BAJA de 50 a 44 us, y es el extrinsic dominado por el
verify Ed25519, el mas sensible al silicio. Antes de mainnet hay que
regenerar en el Pi 5 con governor y aislamiento declarados — peticion
abierta a Laurha (request:66f500d54e28a80c) con el blob, el comando y
la version exacta del bencher.

RV12 -> RV13 (weights = consenso). TRANSACTION_VERSION intacto.
295 tests verde.

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

scripts/bench/regen-weights.sh

@@ -58,14 +58,18 @@ fi
 echo "blob: $( (shasum -a 256 "$WASM" 2>/dev/null || sha256sum "$WASM") | cut -d' ' -f1)"
 
 echo "═══ 2/2 midiendo (steps=$STEPS repeat=$REPEAT) ═══"
-declare -A DEST=(
-  [origin_chain_provenance]=crates/origin-chain-provenance/src/weights.rs
-  [origin_chain_agent_identity]=crates/origin-chain-agent-identity/src/weights.rs
-  [origin_chain_fees]=crates/origin-chain-fees/src/weights.rs
-  [origin_chain_emission]=crates/origin-chain-emission/src/weights.rs
-  [origin_chain_governance]=crates/origin-chain-governance/src/weights.rs
-)
-for p in "${!DEST[@]}"; do
+PARES="
+origin_chain_provenance:crates/origin-chain-provenance/src/weights.rs
+origin_chain_agent_identity:crates/origin-chain-agent-identity/src/weights.rs
+origin_chain_fees:crates/origin-chain-fees/src/weights.rs
+origin_chain_emission:crates/origin-chain-emission/src/weights.rs
+origin_chain_governance:crates/origin-chain-governance/src/weights.rs
+"
+# Lista plana y no array asociativo a proposito: el bash por defecto de macOS
+# es el 3.2, que no tiene `declare -A`, y con `set -u` falla con un
+# «unbound variable» que no se parece en nada a la causa.
+echo "$PARES" | while IFS=: read -r p dest; do
+  [ -n "$p" ] || continue
   echo "── $p"
   "$BENCHER" v1 benchmark pallet \
     --runtime "$WASM" --genesis-builder-preset development \
@@ -73,7 +77,7 @@ for p in "${!DEST[@]}"; do
     --steps "$STEPS" --repeat "$REPEAT" \
     --template "$ROOT/scripts/bench/origin-weights-template.hbs" \
     --header "$ROOT/scripts/bench/HEADER.txt" \
-    --output "$ROOT/${DEST[$p]}"
+    --output "$ROOT/$dest"
 done
 
 echo "═══ listo — ahora: cargo test --workspace ═══"