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

@@ -0,0 +1,65 @@
+#!/usr/bin/env bash
+# Lanza registry_dashboard en Linux en modo completo, conectando a sqlite_api
+# (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.
+#
+# Por que stagear: fn::run_app guarda local_files/ JUNTO al ejecutable
+# (fn::exe_dir() resuelve /proc/self/exe, asi que un symlink no basta — apunta
+# al binario real en cpp/build). Copiando el binario a su propia carpeta de
+# despliegue, local_files/ se crea alli.
+#
+# Modo de datos: se pasa --api http://127.0.0.1:8484 (datos por HTTP mas el
+# stream en vivo del Monitor tab por WebSocket) y, como segundo argumento, el
+# path a registry.db. Si sqlite_api no responde, el binario cae automaticamente
+# 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/,
+# cuatro niveles por debajo de la raiz de fn_registry.
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+ROOT="$(cd "$SCRIPT_DIR/../../../.." && pwd)"
+
+BIN_SRC="$ROOT/cpp/build/apps/registry_dashboard/registry_dashboard"
+ASSETS_SRC="$ROOT/cpp/build/apps/registry_dashboard/assets"
+DB="$ROOT/registry.db"
+APP_HOME="$HOME/fn_apps/registry_dashboard"
+
+if [ ! -x "$BIN_SRC" ]; then
+    echo "Binario no encontrado: $BIN_SRC" >&2
+    echo "Compila primero:" >&2
+    echo "  cmake -S $ROOT/cpp -B $ROOT/cpp/build -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF" >&2
+    echo "  cmake --build $ROOT/cpp/build --target registry_dashboard -j\$(nproc)" >&2
+    exit 1
+fi
+
+if [ ! -f "$DB" ]; then
+    echo "registry.db no encontrado: $DB" >&2
+    echo "Regenera el indice: (cd $ROOT && ./fn index)" >&2
+    exit 1
+fi
+
+# Stage del ejecutable + assets a su carpeta de despliegue. -u copia solo si la
+# fuente es mas nueva, asi que tras un rebuild se actualiza automaticamente.
+# local_files/ NO se toca: persiste config y layouts entre lanzamientos.
+mkdir -p "$APP_HOME"
+cp -u "$BIN_SRC" "$APP_HOME/registry_dashboard"
+if [ -d "$ASSETS_SRC" ]; then
+    mkdir -p "$APP_HOME/assets"
+    cp -ru "$ASSETS_SRC/." "$APP_HOME/assets/"
+fi
+
+# Lanzar desde APP_HOME → fn::exe_dir() apunta aqui → local_files/ vive aqui.
+# --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 "http://127.0.0.1:8484" "$DB"