refactor(monorepo): reorganización lógica + renames + SDDs + split CHANGELOG

Reorganización física de crates/:
- core/ (mezclaba 6 propósitos) se divide en protocol/, init/, runtime/, compat/
- shared/ (3 crates) se redistribuye en protocol/ e init/
- lapaloma (sub-módulo de ui_engine) se promueve a modules/pineal/

Renames de proyectos:
- shipote → shuma (runtime de sandboxes)
- nouser → akasha (explorador de Mónadas)
- yahweh → nahual (motor GPUI, antes ui_engine/)
- lapaloma → pineal (data-viz agnóstica)

Fraccionamiento UI → core agnóstico:
- vista-core (DeckState + snap, 175 LOC, 5 tests verdes)
- barra-core (Task + render_html + sanitize, 90 LOC, 5 tests verdes)
- vista-web y barra-web ahora son thin DOM bindings

Documentación nueva:
- 16 SDDs por subdirectorio (≤80 LOC c/u): protocol/init/runtime/compat
  + 10 módulos + apps/
- docs/STATUS.md con cifras reales por proyecto
- docs/ROADMAP.md con plan a finalización (6 hitos, ~6-8 semanas)
- CHANGELOG.md particionado en docs/changelog/<proyecto>.md (7 buckets)

Automatización:
- scripts/reorg.py — script idempotente que: git mv directorios, renombra
  package names, recomputa path = refs, reescribe imports rust, actualiza
  workspace Cargo.toml. Soporta --dry-run.
- scripts/split-changelog.py — particiona CHANGELOG por componente.

Validación:
- cargo check --workspace pasa (124 crates + 2 nuevos cores).
- 10 tests adicionales (5 en vista-core + 5 en barra-core) verdes.

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

crates/modules/nahual/libs/bus/Cargo.toml

@@ -0,0 +1,9 @@
+[package]
+name = "nahual-bus"
+version = { workspace = true }
+edition = { workspace = true }
+license = { workspace = true }
+description = "AppBus + AppEvent — comunicación cross-widget app-level."
+
+[dependencies]
+gpui = { workspace = true }

crates/modules/nahual/libs/bus/src/lib.rs

@@ -0,0 +1,44 @@
+//! `nahual_bus` — `AppBus` + `AppEvent` para comunicación cross-widget.
+//!
+//! Es un `Entity<AppBus>` que emite [`AppEvent`]. Cualquier widget se
+//! subscribe con `cx.subscribe(&bus, |this, _, ev, cx| { ... })`. La
+//! Shell crea exactamente un AppBus al boot y lo distribuye:
+//!
+//! - **Productores** (FileExplorer, DatabaseExplorer): el LayoutHost los
+//!   subscribe individualmente y reenvía sus eventos tipados al bus,
+//!   normalizando al formato `{provider, id, …}` agnóstico.
+//! - **Consumidores** (TextViewer, ImageViewer, …): reciben el handle del
+//!   bus en su constructor y se subscriben directo.
+//!
+//! Por qué un bus y no `cx.subscribe` directo entre productor y consumidor:
+//! los viewers no saben qué explorers existen (ni viceversa). El bus
+//! desacopla — puede haber 0, 1 o N explorers de distintos providers, y
+//! varios viewers en paralelo viendo el mismo evento.
+
+use gpui::EventEmitter;
+
+/// Eventos cross-widget. Diseñados para ser agnósticos del dominio:
+/// `provider` es el id (string) del DataProvider que sabe interpretar el
+/// `id`. `provider_path` es el contexto opcional (ej. el .sqlite del
+/// DatabaseExplorer) que el viewer necesita para construir su provider.
+#[derive(Clone, Debug)]
+pub enum AppEvent {
+    /// Una entidad fue seleccionada (single click). Suele triggerear un
+    /// preview en el viewer activo.
+    EntitySelected {
+        provider: String,
+        provider_path: Option<String>,
+        id: String,
+    },
+    /// Una entidad fue ejecutada (doble click u "Open" del menú).
+    EntityOpened {
+        provider: String,
+        provider_path: Option<String>,
+        id: String,
+    },
+}
+
+#[derive(Default)]
+pub struct AppBus;
+
+impl EventEmitter<AppEvent> for AppBus {}