feat: merge Oasis 0.7.6 upstream — Graphos, E2E, peers/stats, AUTOMATIZACION

Cambios aplicados desde epsylon/oasis 3d46340 (0.7.6):

NUEVO MÓDULO Graphos (mapa interactivo de la red):
- src/views/graphos_view.js (nuevo)

LÓGICA:
- src/backend/nameCache.js (nuevo) — NameAuthor resolver
- src/models/chats_model.js — encriptación E2E
- src/models/calendars_model.js — E2E + calendar invites con códigos
- src/models/maps_model.js — E2E + CLOSED enforcement
- src/models/tribes_model.js — sub-tribe access control (PRESERVA nuestro inviteLog)
- src/models/tribe_crypto.js — soporte E2E
- src/models/main_models.js — refactor (PRESERVA nuestro pub-invite SSB msg)
- src/models/{activity,banking,pads,search,stats,tags,tribes_content}_model.js
- src/backend/backend.js — searchModel constructor + new helpers (errorView, safeRefererRedirect)
- src/backend/blobHandler.js, renderTextWithStyles.js
- src/views/main_views.js — añadido userLink/userLinkLabel + nameCache import (mantiene nuestro hamburger menu)

VISUAL:
- 31 views actualizadas con refactor a userLink helper
- src/views/peers_view.js — tabla con keys clicables
- src/views/stats_view.js — dashboard avanzado
- src/client/assets/styles/style.css — merge (preserva nuestras adiciones QR/mobile)
- Temas desktop: Clear, Dark, Matrix, Purple
- Translations 11 idiomas (ar, de, en, es, eu, fr, hi, it, pt, ru, zh)
- src/configs/{config-manager,oasis-config}, server/SSB_server.js, oasis_client.js

SKIPS (intencionalmente):
- OasisMobile.css del upstream (mantenemos NUESTRO mobile.css y theme)
- main_views.js menu reorganization (mantenemos hamburger nav)
- @xenova/transformers (LLM, no viable mobile)
- node-llama-cpp (build nativo no soportado en arm64 mobile)
- pdfjs-dist (pendiente probar luego)
- AI/embedder.js + AI/routes_index.js (dependen de las libs LLM)

server/package.json: version 0.7.5 → 0.7.6

AUTOMATIZACIÓN:
- Nueva carpeta AUTOMATIZACION/ con 10 archivos:
  - 4 opciones (cron simple, multi-agente, GitHub Actions, webhook)
  - Setup Debian completo paso a paso
  - Scripts bash listos: scout, merger, builder, notify-telegram
  - Prompts listos para los agentes
  - Sección /testing-app para 0asis.net
  - Human-in-the-loop: archivos prohibidos para auto-merge

PENDIENTE: build APK (el bash tool tuvo timeouts; usar comandos
de CONTEXT/cambio_apk_repack.txt manualmente).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

AUTOMATIZACION/01_OPCIONES.txt

@@ -0,0 +1,102 @@
+===============================================================
+  OPCIONES DE AUTOMATIZACIÓN — Comparativa
+===============================================================
+
+OPCIÓN A — CRON + CLAUDE HEADLESS (SIMPLE)
+==========================================
+Un cron semanal en Debian. Un único script que invoca claude
+con un prompt grande pidiendo que lo haga todo de cabo a rabo.
+
+PROS:
+  - Setup en 30 minutos
+  - Sin infra extra (solo cron)
+  - Cero costes adicionales
+
+CONTRAS:
+  - Un único punto de fallo
+  - Si claude se atasca en un conflicto, todo se queda colgado
+  - Sin recuperación parcial
+  - Difícil debuggear cuándo va mal
+
+CUÁNDO USARLA:
+  - Cuando solo se quiere probar el concepto
+  - Cuando los cambios upstream son pequeños y predecibles
+
+
+OPCIÓN B — MULTI-AGENTE (RECOMENDADA)
+=====================================
+Tres agentes especializados en cron. Cada uno con su prompt
+corto, su contexto, y su responsabilidad clara.
+
+  scout    | Lun 03:00 | git fetch + analiza diff + reporta
+  merger   | Lun 04:00 | aplica cambios safe + abre PR
+  builder  | Lun 05:00 | build APK + sube + notifica
+
+PROS:
+  - Fallo aislado (si scout falla, merger no se ejecuta)
+  - Prompts cortos = menos tokens = más barato y fiable
+  - Logs separados por agente
+  - Recuperable: puedes re-ejecutar solo el que falló
+  - Auditable: cada agente deja su reporte en disco
+
+CONTRAS:
+  - Más setup inicial (3 crons, 3 prompts)
+  - Hay que orquestar dependencias (merger depende de scout)
+
+CUÁNDO USARLA:
+  - Cuando los cambios upstream son frecuentes y variados
+  - Cuando quieres ver QUÉ va a aplicar antes de aplicarlo
+
+
+OPCIÓN C — GITHUB ACTIONS
+=========================
+Workflow en .github/workflows/weekly-merge.yml del repo
+oasis_mobile. Trigger en cron + manual dispatch.
+
+PROS:
+  - Gratis (2000 min/mes en repo público o privado básico)
+  - Histórico completo de runs visible
+  - Artifacts descargables (la APK)
+  - Logs públicos si lo quieres
+  - Cero infraestructura propia
+
+CONTRAS:
+  - Timeout máximo 6h por job
+  - Build APK consume bastante (10-15 min)
+  - El repo debe estar en GitHub (no en Gitea code.03c8.net)
+  - Secrets: ANTHROPIC_API_KEY visible para todos los maintainers
+
+CUÁNDO USARLA:
+  - Si planeas mover el repo a GitHub
+  - Si no tienes VPS o no quieres gestionarlo
+
+
+OPCIÓN D — WEBHOOK REACTIVO
+===========================
+Webhook de GitHub apuntando a un endpoint en tu VPS. Cuando
+epsylon publica un release, dispara inmediatamente el pipeline.
+
+PROS:
+  - Reacción casi en tiempo real (segundos)
+  - No esperas al cron del lunes
+  - El pipeline puede ser tan complejo como quieras
+
+CONTRAS:
+  - Requiere VPS público con dominio + HTTPS
+  - Hay que mantener el endpoint
+  - Si el webhook falla, hay que tener un cron de respaldo
+
+CUÁNDO USARLA:
+  - Cuando quieres lo más rápido posible
+  - Cuando tienes ya un VPS funcionando
+
+
+COMBINACIÓN RECOMENDADA: B + D
+==============================
+- Webhook (D) dispara scout (de B)
+- Cron de seguridad cada lunes 03:00 también ejecuta scout
+  (por si el webhook falla)
+- Resto del pipeline (merger + builder) es B
+
+Mejor de los dos mundos: rápido pero con respaldo, modular,
+auditable, recuperable.