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.

launch_linux.sh

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
-# Lanza registry_dashboard en Linux con binding SQLite directo (sin sqlite_api),
-# stageando el ejecutable a ~/fn_apps/registry_dashboard/ para que todos los
+# 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.
@@ -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
-# cae a SQLite directo si la API falla. Ese puente HTTP existia porque antes el
-# binario corria en Windows y los datos vivian en WSL. En Linux nativo el
-# registry.db es local, asi que forzamos el binding directo con --api "".
+# 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/,
@@ -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"