fix(slice-4): service.rs/rpc.rs corrected (Block root + verbatim CIDP) + §11 honest finding

Slice 4 checkpoint tras intentar Opción C (David: stack consistente del tag).
Build verde, 213 tests, sin regresiones. Node sigue CLI+chain_spec (mods off).

=== Correcciones a service.rs/rpc.rs (preservadas para wire-in) ===
- Block root (no opaque::Block): el runtime expone impl_runtime_apis! sobre el
  Block root con UncheckedExtrinsic, no un opaque block separado. rpc.rs igual.
- CIDP verbatim del template restaurado: standalone::slot_duration_at +
  inherents::InherentDataProvider::from_timestamp_and_slot_duration. AMBOS existen
  en sp-consensus-aura 0.45.0 PUBLICADO (verificado inherents.rs:61). Mi 'fix'
  v0.0.49 (Slot::from_timestamp) era incorrecto — revertido.

=== §11 corrige §10.2 (diagnóstico honesto) ===
El problema NO era API gap (las APIs existen) ni elegir bien versiones publicadas.
Es estructural del ecosistema: polkadot-sdk publica sus ~15 sub-crates sc-* en
cadencias distintas → NO existe isla de versiones publicadas internamente
consistente que reproduzca el tag. Verificado vía sparse index:
- sc-consensus-aura 0.52.0 → sp-consensus-aura ^0.44; 0.53.0/0.53.1 → ^0.45;
  0.54.0 → ^0.44 (oscila entre generaciones en patches consecutivos)
- sc-service 0.54.1 (versión del tag) NO publicada en crates.io
El tag solo es consistente vía su Cargo.lock commiteado en el monorepo git.

=== Recomendación senior para David (§11.4) ===
Diferir node service real al setup de infra Phase 4 testnet (que necesita build
env con red git de todos modos). NO seguir adivinando versiones publicadas (no
convergen). Firmes: WASM export (v0.0.48) + core2 unblock (v0.0.49) +
service.rs/rpc.rs correctos. Wire-in ~1 sesión cuando haya env con git fetch
O un Cargo.lock del monorepo stable2509-3.

Verificación: cargo check -p origin-chain-node verde (mods off) + 213 tests verde.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

docs/SLICE_4_SC_SERVICE_IMPLEMENTATION_PLAN_V1.md

@@ -648,4 +648,53 @@ polkadot-sdk reusa números de versión con cambios git no publicados (el mismo
 
 ---
 
-— Charon ⚓ (Pilar 4, Slice 4 plan V1 + §10 hallazgos ejecución v0.0.48-49, sesión 4+ 2026-05-27)
+---
+
+## §11 — CORRECCIÓN del diagnóstico §10.2 + estado v0.0.50 (Opción C, David)
+
+David eligió **Opción C** (stack consistente del tag). Al ejecutarla descubrí que **mi diagnóstico §10.2 era parcialmente erróneo** — corrección honesta:
+
+### §11.1 — El problema NO era "API gap" — era duplicate-crate por generación sc-* incorrecta
+
+Las APIs SÍ existen en las crates publicadas (lo verifiqué en el source local):
+- `sc-consensus-aura 0.52 standalone::slot_duration_at` → existe (standalone.rs:58)
+- `sp-consensus-aura 0.45 inherents::InherentDataProvider::from_timestamp_and_slot_duration` → existe (inherents.rs:61)
+
+El `service.rs` verbatim del template **era correcto**; mis "fixes" de v0.0.49 (cambiar a `slot_duration_at` root + `Slot::from_timestamp`) lo rompieron. **Revertidos a verbatim en v0.0.50.**
+
+El problema REAL: el lock tenía **dos generaciones simultáneas** (`sp-consensus-aura 0.44.0 + 0.45.0`, `sp-timestamp 38 + 39`). Mis pins `sc-*` (0.52/0.53) eran de una generación **distinta** a mis `sp-*/frame-*` (0.45/44) → duplicate-crate → los ~50 trait-bound errors (`sp_io::*::HostFunctions not satisfied`, `P: TransactionPool not satisfied`, etc. son todos síntomas de tipos de dos copias del mismo crate).
+
+### §11.2 — Opción C choca con el publishing inconsistente de polkadot-sdk
+
+Intenté lograr Opción C **vía versiones publicadas** en crates.io (la red git falla en este entorno — core2 fetch dio Eof, así que clonar el monorepo no es viable). El intento reveló el muro real, verificado con el sparse index de crates.io:
+
+`sc-consensus-aura` → `sp-consensus-aura` requerido, por versión publicada:
+- `0.52.0` → `^0.44.0`
+- `0.53.0` → `^0.45.0` ✓ (mi generación)
+- `0.53.1` → `^0.45.0` ✓
+- `0.54.0` → `^0.44.0` (¡vuelve a 0.44!)
+
+El número de versión **oscila** entre generaciones de sp-* en patches consecutivos. Y peor: **`sc-service 0.54.1` (la versión del tag stable2509-3) NO está publicada en crates.io** (`cargo info sc-service@0.54.1` → "could not find"). polkadot-sdk publica sus ~15 sub-crates sc-* en cadencias distintas, de modo que **no existe una isla de versiones publicadas internamente consistente** que reproduzca el tag. El tag solo es consistente vía su `Cargo.lock` commiteado en el monorepo git.
+
+Conclusión dura (corrige §10.2): el problema NO es "API gap" (las APIs existen) ni "elegir bien las versiones publicadas" (no hay set consistente). El problema es **estructural del ecosistema**: un node service real requiere el `Cargo.lock` del monorepo git, que necesita un entorno con red git funcional.
+
+### §11.3 — Lo que SÍ quedó firme + lo correcto preservado
+
+- **WASM_BINARY export (Paso 4a)** — ✅ shipped v0.0.48, verde.
+- **core2 yanked unblock** — ✅ shipped v0.0.49 (vendor path patch), verde.
+- **service.rs + rpc.rs** — corregidos a la forma correcta y preservados como archivos (mods off):
+  - `Block` root (no `opaque::Block`) — el runtime expone `impl_runtime_apis!` sobre el Block root.
+  - CIDP verbatim del template (`standalone::slot_duration_at` + `inherents::InherentDataProvider::from_timestamp_and_slot_duration`) — ambos SÍ existen en sp-consensus-aura 0.45.0 publicado (verificado en source: inherents.rs:61). Mi "fix" de v0.0.49 (`Slot::from_timestamp`) era incorrecto; revertido a verbatim.
+- Workspace Cargo.toml — en el estado verde de v0.0.49 (sc-* sin tocar; node compila con mods off).
+
+### §11.4 — Decisión real para David (recomendación senior)
+
+El node service real es construible, pero **requiere un entorno con red git** para usar los git sources del tag (con su Cargo.lock consistente). Eso es exactamente el entorno que Phase 4 testnet necesita de todos modos (CI/CD + build de validadores Pi 5). Por lo tanto:
+
+**Recomendación**: diferir el node service real al setup de infraestructura de Phase 4 testnet, donde montamos un build env con red git + `cargo build` desde el monorepo pinned. NO seguir adivinando versiones publicadas una por una (no convergen). Mientras tanto el node sigue siendo CLI + chain_spec builder funcional, y todo lo demás de Slice 4 (WASM export + core2 unblock + service.rs/rpc.rs correctos) queda firme para wire-in inmediato cuando el env esté listo.
+
+Alternativa si quieres node YA: dame un entorno con `git fetch` habilitado (o un Cargo.lock del monorepo stable2509-3 que yo consuma), y wire-in es ~1 sesión.
+
+---
+
+— Charon ⚓ (Pilar 4, Slice 4 plan V1 + §10 + §11 corrección honesta Opción C, sesión 4+ 2026-05-27. WASM export + core2 unblock firmes; node real diferido a env con red git por publishing inconsistente del ecosistema.)