feat(linux): launcher de escritorio con binding SQLite directo

Anade launch_linux.sh y appicon.png para correr el dashboard en Linux nativo:
- Stagea el ejecutable + assets a ~/fn_apps/registry_dashboard/ y lanza desde
  alli, de modo que local_files/ (imgui.ini, app_settings.ini, layouts.db, logs)
  queda contenido en esa carpeta en lugar del arbol de build o el escritorio.
- Fuerza --api "" para leer registry.db directo y prescindir de sqlite_api
  (el puente HTTP solo hacia falta cuando el binario corria en Windows con los
  datos en WSL).
- appicon.png: rasterizado del appicon.ico para el icono del .desktop.

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

launch_linux.sh

@@ -0,0 +1,56 @@
+#!/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
+# 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.
+#
+# 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 "".
+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 "" fuerza binding SQLite directo (salta el intento HTTP a sqlite_api).
+cd "$APP_HOME"
+exec "$APP_HOME/registry_dashboard" --api "" "$DB"