chore: monorepo inicial con arje + minga + yahweh absorbidos

Workspace en 4 ejes (core/modules/apps/shared):

- core/: 24 crates de arje (Init systemd-compatible: ente-card, ente-zero,
  ente-kernel, ente-bus, ente-cas, ente-soma, ente-wasm, ente-snapshot,
  ente-brain, ente-echo, ente-policy-provider, + 12 crates *-compat)
- modules/semantic_dht/: 5 crates de minga (minga-core con AST/CAS/MST,
  minga-p2p con libp2p Kad, minga-store, minga-vfs, minga-cli)
- modules/ui_engine/: 11 crates de yahweh (libs/{core,theme,bus,providers},
  widgets/{tree,splitter,tabs,tiled,container_core,text_input})
- apps/: 5 crates de yahweh (file_explorer, database_explorer, text_viewer,
  image_viewer, yahweh-shell)
- shared_wit/protocol.wit: handshake/lifecycle inicial

Cargo.toml unificado: thiserror bumped a 2 (transparente para arje), tokio
"full", paths intra-workspace de yahweh redirigidos a su nueva ubicación.

cargo check --workspace: 0 errores, 17 warnings (dead code preexistente).

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

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

@@ -0,0 +1,44 @@
+//! `yahweh_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 {}