docs(issues): roadmap fase 2 navegador + ports Go + runtime embebido

Anade siete issues que definen el camino para hacer graph_explorer
distribuible como binario Windows autocontenido (sin WSL):

- 0032 — browser_session enrichers via Playwright (login interactivo,
  cookies persistentes, fetch_webpage_browser, web_search_browser).
- 0033 — dispatcher multi-lenguaje (lang: go|python|bash en manifest)
  + runtime Python embebido en <app>/runtime/. 3 fases (A=dispatcher,
  B=runtime, C=UI badges).
- 0033b — vendoring de funciones Python por enricher (_vendored/ +
  .vendor.lock) para que los enrichers no dependan de registry_root
  en runtime.
- 0033c — fn check vendored: drift detection con --fix.
- 0033d — fn index lee python_runtime / python_runtime_deps de app.md.
- 0033e — /compile orquesta freeze + vendor + go builds.
- 0034 — port de los 5 enrichers de sistema a Go. Reusa funciones
  Go del registry directamente (no copias). Tests pytest existentes
  pasan sin cambios.

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

issues/0033b-vendor-python-functions.md

@@ -0,0 +1,69 @@
+---
+id: 0033b
+title: Vendoring de funciones Python por enricher
+status: pending
+priority: high
+created: 2026-05-02
+depends_on: [0033]
+---
+
+## Objetivo
+
+Para que el `.exe` Windows sea portable a cualquier PC, los enrichers
+con `lang: python` no pueden importar de `<registry_root>/python/functions/`
+en runtime. Cada enricher copia las funciones del registry que
+declara en `uses_functions` a `<enricher>/_vendored/` durante el
+build, y `run.py` importa de ahi.
+
+## Implementacion
+
+### 1. Script `tools/vendor_enricher_python.sh`
+
+Recibe `<enricher_dir>` y `<registry_root>`. Lee `uses_functions` del
+manifest, filtra los IDs `*_py_*`, resuelve `file_path` desde
+`registry.db`, copia el `.py` a `_vendored/<domain>/<name>.py` y
+crea `__init__.py` por dominio. Genera `.vendor.lock` con
+`<id>  <sha256>  <src_path>` por linea. Idempotente: si el sha256 de
+origen coincide con el del lock, no copia.
+
+### 2. Adaptacion de `run.py`
+
+Cada enricher con `lang: python` que use funciones del registry
+cambia el import:
+
+```python
+# antes
+sys.path.insert(0, os.path.join(registry_root, "python", "functions"))
+from cybersecurity.cybersecurity import normalize_url
+
+# despues
+sys.path.insert(0, os.path.join(os.path.dirname(__file__), "_vendored"))
+from cybersecurity.normalize_url import normalize_url
+```
+
+### 3. .gitignore
+
+Anadir `_vendored/` y `.vendor.lock` al `.gitignore` del repo (o de
+cada app). Son artefactos de build, regenerables.
+
+### 4. Hook al build
+
+`/compile` (o el script de freeze del 0033) recorre
+`apps/<app>/enrichers/*/manifest.yaml`. Para cada manifest con
+`lang: python`, ejecuta `vendor_enricher_python.sh`.
+
+## Tests
+
+- Test unit del script bash: dado un manifest con dos `uses_functions`
+  Python conocidas, verificar que `_vendored/` queda con la estructura
+  correcta y `.vendor.lock` lista los hashes.
+- Test e2e: `fetch_webpage` (lang: python) ejecuta correctamente con
+  registry_root vacio en el ctx tras vendoring.
+
+## Definicion de hecho
+
+- `tools/vendor_enricher_python.sh` existe y es idempotente.
+- Cada enricher Python del proyecto tiene `_vendored/` poblado y
+  funciona sin `registry_root` en runtime.
+- El binario zippeado a Desktop arranca enrichers Python sin acceso
+  al fn_registry.