feat(nouser): Phase B-2 — daemon que publica Mónadas al Init brahman

Cierra la unificación ontológica de B-1: el nouser daemon se
sidecarea como Ente y publica cada Mónada como su propia sesión Data.
Un solo brahman-status muestra procesos y datos en la misma lista.

Cambios:

- nouser-core gana deps brahman-card + brahman-sidecar.
- bin nouser nuevo subcomando: daemon <dir>.
  1. Spawna sidecar para el engine (brahman.nouser_engine, kind=Ente):
     el "ser" que produce y administra Mónadas.
  2. Scan + cluster del directorio.
  3. Para cada Mónada, monad.to_brahman_card() + sidecar (kind=Data).
     Cada Mónada es una sesión brahman propia, con su ULID estable.
  4. Park del main thread; los sidecars siguen pingueando.

Validación end-to-end:

  $ ente-zero &
  $ NOUSER_MIN_FILES=5 nouser daemon crates/core &
  $ brahman-status

  Sessions (6):
    [ente]  ... brahman.nouser_engine  lifecycle=Daemon
    [data]  ... src    summary: 5 archivos en crates/core/brahman-admin/src
                       members: 5 (dispersion=0.00)  lens hint: code
    [data]  ... src    summary: 11 archivos en crates/core/ente-brain/src
    [data]  ... graph  summary: 7 archivos en crates/core/ente-zero/src/graph
    ...

La función de presentarse es la misma para procesos y datos. UI ve
una lista uniforme y discrimina por `kind` cuando le importa.

Costo conocido: cada Mónada consume thread + tokio runtime
current_thread (legacy del sidecar API). Para escalar a >50 Mónadas
conviene consolidar en un único runtime con N tasks. Defer a B-3.

Pendientes propuestos (en CHANGELOG):
- B-3: consolidar sidecars en un solo runtime.
- C: pseudo-embeddings + atracción por centroide.
- D: módulo nouser-nous para LLM, swappable por priority_contexts.
- Polish: labels con 2-3 componentes de path.
- Crossreferencia: Ente anuncia "procesando Mónada X", Mónada anuncia
  "siendo procesada por Ente Y".

cargo check --workspace: 0 errores, 0 warnings.

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

CHANGELOG.md

@@ -6,6 +6,60 @@ ratio/diff ver `git show <sha>`.
 
 ## 2026-05-08
 
+### feat(nouser): Phase B-2 — daemon que publica Mónadas al Init
+Cierra la unificación: el `nouser daemon` se sidecarea como Ente y
+publica cada Mónada como su propia sesión Data. Un solo
+`brahman-status` muestra procesos y datos en la misma lista, exactamente
+como buscaba el diseño.
+
+Cambios:
+
+- `crates/modules/nouser/core/Cargo.toml`: deps nuevas `brahman-card`
+  y `brahman-sidecar`.
+- `crates/modules/nouser/core/src/bin/nouser.rs`: subcomando
+  `daemon <dir>`.
+  - Spawna un sidecar para el "engine" (`brahman.nouser_engine`,
+    kind=Ente) — el ser que produce y administra Mónadas.
+  - Scan + cluster del dir.
+  - Para cada Mónada, llama `monad.to_brahman_card()` y spawnea un
+    sidecar (kind=Data). Cada Mónada es una sesión brahman propia
+    con su ULID estable.
+  - Park del thread principal: los sidecars siguen pingueando.
+
+Validación end-to-end:
+
+  $ ente-zero &
+  $ NOUSER_MIN_FILES=5 nouser daemon crates/core &
+  $ brahman-status
+
+  Sessions (6):
+    [ente]  ... brahman.nouser_engine  lifecycle=Daemon
+    [data]  ... src    summary: 5 archivos en crates/core/brahman-admin/src
+                       members: 5 (dispersion=0.00)
+                       lens hint: code
+    [data]  ... src    summary: 11 archivos en crates/core/ente-brain/src
+                       ...
+    [data]  ... graph  summary: 7 archivos en crates/core/ente-zero/src/graph
+
+El protocolo de presentación es uno solo: la Card. La función — anunciar
+identidad, exponer metadata, ser descubierto — es idéntica para procesos
+vivos y agrupaciones de datos. La UI lo ve como una lista uniforme.
+
+Costo conocido: cada Mónada consume un thread + tokio runtime
+current_thread (legacy del sidecar API). Para muchas Mónadas (>50)
+conviene consolidar en un único runtime con N tasks. Defer a Phase B-3.
+
+Pendientes propuestos:
+- **B-3**: consolidar todos los sidecars en un único runtime tokio
+  para no spawnear N threads.
+- **C**: pseudo-embeddings + atracción por centroide.
+- **D**: módulo `nouser-nous` para LLM, swappable por priority_contexts.
+- **Polish**: labels con 2-3 componentes del path.
+- **Crossreferencia**: que un Ente pueda anunciar "estoy procesando la
+  Mónada X" y la Mónada anuncie "Ente Y me está procesando".
+
+cargo check --workspace: 0 errores, 0 warnings.
+
 ### feat: Phase B-1 — unificación ontológica de Cards (Ente ↔ Data)
 La Card es **el** protocolo de presentación del ecosistema, no sólo de
 los procesos. Una Mónada Nouser y un Ente Brahman son ambos "entidades