feat(launcher): launch_linux.sh arranca en modo completo (HTTP+WS+Work)

Antes forzaba --api "" (binding SQLite directo), lo que desactivaba el
WebSocket del Monitor tab. Ademas no exportaba FN_REGISTRY_ROOT, por lo que la
tab Work no encontraba el binario dev_console y caia a un placeholder.

Ahora pasa --api http://127.0.0.1:8484 con registry.db como segundo argumento
de fallback (el binario cae a SQLite directo si el servicio no responde) y
exporta FN_REGISTRY_ROOT. El resultado es la app completa con un solo comando,
con degradacion elegante cuando sqlite_api no esta arriba.

app.md

@@ -59,6 +59,16 @@ Dashboard C++ con dos modos de acceso a datos:
 - Pie charts: pureza (pure/impure), kind (function/pipeline/component)
 - Tablas: ultimas 20 funciones, apps, analysis, tipos
 
+## Dependencias de runtime (otras apps)
+
+Ademas de las funciones, tipos y modulos del registry declarados en el frontmatter (`uses_functions`, `uses_modules`), el dashboard depende en tiempo de ejecucion de tres apps del ecosistema `fn_monitoring`. Estas dependencias no se expresan en el frontmatter porque el schema de la tabla `apps` no tiene un campo para dependencias entre apps; se documentan aqui.
+
+| App | Acoplamiento | Para que | Si falta |
+|-----|--------------|----------|----------|
+| `sqlite_api` (`projects/fn_monitoring/apps/sqlite_api`, servicio HTTP en `:8484`) | HTTP `POST /api/databases/...` + WebSocket `/api/events/call_monitor` | Fuente primaria de datos (`registry.db`) y stream en vivo del Monitor tab | El dashboard cae al modo SQLite directo (`--api ""` mas un path a `registry.db`). El Monitor tab pierde el stream en vivo y solo muestra el snapshot inicial. |
+| `call_monitor` (`projects/fn_monitoring/apps/call_monitor`, telemetria) | Indirecto: escribe su `operations.db`, que `sqlite_api` lee y reenvia por WebSocket | Eventos del Monitor tab (`calls`, `violations`, ejecuciones recientes) | El Monitor tab queda vacio. El WebSocket de `sqlite_api` se cierra con `snapshot failed` si la `operations.db` de `call_monitor` no esta registrada en el pool. El registro ocurre al arrancar `sqlite_api`, por lo que un reinicio del servicio la recoge si la base de datos se creo despues. |
+| `dev_console` (`apps/dev_console`, CLI Go) | Subproceso: `dev_console work dashboard --json` invocado via `popen()` cada 30 s (con cache) | Backend de la tab Work (issue 0102): issues, flows y KPIs de DoD | La tab Work muestra un placeholder con el comando de build, sin crash. `work_tab.cpp::find_dev_console()` busca el binario en `$FN_REGISTRY_ROOT/apps/dev_console/dev_console`, asi que el dashboard debe lanzarse con `FN_REGISTRY_ROOT` apuntando a la raiz del repo para que la tab cobre vida. |
+
 ## Build
 
 ```bash

launch_linux.sh

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
-# Lanza registry_dashboard en Linux con binding SQLite directo (sin sqlite_api),
+# Lanza registry_dashboard en Linux en modo completo, conectando a sqlite_api
-# stageando el ejecutable a ~/fn_apps/registry_dashboard/ para que todos los
+# (HTTP + WebSocket), stageando el ejecutable a ~/fn_apps/registry_dashboard/ para que todos los
 # artefactos de runtime (imgui.ini, app_settings.ini, layouts.db, logs) queden
 # contenidos en esa carpeta y no se mezclen con el arbol de build ni con el
 # escritorio.
@@ -10,10 +10,16 @@
 # al binario real en cpp/build). Copiando el binario a su propia carpeta de
 # despliegue, local_files/ se crea alli.
 #
-# El dashboard, por defecto, intenta sqlite_api en http://127.0.0.1:8484 y solo
+# Modo de datos: se pasa --api http://127.0.0.1:8484 (datos por HTTP mas el
-# cae a SQLite directo si la API falla. Ese puente HTTP existia porque antes el
+# stream en vivo del Monitor tab por WebSocket) y, como segundo argumento, el
-# binario corria en Windows y los datos vivian en WSL. En Linux nativo el
+# path a registry.db. Si sqlite_api no responde, el binario cae automaticamente
-# registry.db es local, asi que forzamos el binding directo con --api "".
+# a ese SQLite local, asi que el lanzamiento funciona con o sin el servicio
+# arriba: con servicio se obtiene el Monitor en tiempo real; sin el, datos
+# estaticos del registry.db.
+#
+# Ademas se exporta FN_REGISTRY_ROOT para que la tab Work localice el binario
+# dev_console (apps/dev_console/dev_console), que alimenta su panel de issues,
+# flows y KPIs de DoD. Sin esa variable la tab Work cae a un placeholder.
 set -euo pipefail
 
 # Raiz del repo: este script vive en projects/fn_monitoring/apps/registry_dashboard/,
@@ -51,6 +57,9 @@ if [ -d "$ASSETS_SRC" ]; then
 fi
 
 # Lanzar desde APP_HOME → fn::exe_dir() apunta aqui → local_files/ vive aqui.
-# --api "" fuerza binding SQLite directo (salta el intento HTTP a sqlite_api).
+# --api http://127.0.0.1:8484 activa HTTP + WebSocket (Monitor en vivo); el path
+# a registry.db queda como fallback si sqlite_api no responde. FN_REGISTRY_ROOT
+# permite que la tab Work localice el binario dev_console.
+export FN_REGISTRY_ROOT="$ROOT"
 cd "$APP_HOME"
-exec "$APP_HOME/registry_dashboard" --api "" "$DB"
+exec "$APP_HOME/registry_dashboard" --api "http://127.0.0.1:8484" "$DB"