feat: cierra issues 0050 y 0052 + commands automáticos

- 0050: jupyter_exec reescrito sin Y.js (REST + KernelClient). Bug raíz adicional: HEAD /api/contents da 405 → cambiado a GET. 9 tests (5 unit + 4 e2e).
- 0052: footprint_aurgi cerrado. Bug fix en setup_geo_stack_docker_pipeline (verify aborta si compose up falla; nombre de contenedor incorrecto).
- Nueva primitiva docker_container_running_py_infra (7 tests).
- /full-git-push y /full-git-pull pasan a modo automático: auto-commit + push sin preguntar, aborta solo si detecta secrets.

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

dev/issues/completed/0050-jupyter-exec-collab-client-failure.md

@@ -1,3 +1,30 @@
+# 0050 — `jupyter_exec` falla por cliente colaborativo (RESUELTO 2026-05-05)
+
+## Cierre (2026-05-05)
+
+Resuelto via opcion (b) del propio issue: migrar `jupyter_exec` a REST + `KernelClient`
+clasico, bypassando `NbModelClient`/Y.js.
+
+Bug raiz adicional encontrado al reproducir: `_notebook_exists` usaba `HEAD /api/contents`,
+y Jupyter Server responde **405 Method Not Allowed** (no soporta HEAD ahi). Cambiado a
+`GET /api/contents?content=0`.
+
+Cambios:
+- `python/functions/notebook/jupyter_exec.py` reescrito (v2.0.0). Sync, sin asyncio.
+  Append/cell ahora usan REST `/api/contents` para leer/escribir celdas + outputs y
+  `KernelClient` para ejecutar.
+- `python/functions/notebook/tests/test_jupyter_exec.py` con 5 tests unitarios
+  (incluye guard para que HEAD no vuelva) y 4 tests e2e que arrancan un Jupyter Lab
+  en puerto libre con `--collaborative` y verifican los tres modos.
+- 9/9 tests pasan en local.
+
+Trade-off documentado en el `.md`: los cambios se persisten a disco; Jupyter Lab los
+detecta y muestra en el browser (puede pedir 'Revert to disk' segun version y
+conflictos). Esto basta para los analyses del proyecto y es lo que ya se hacia con el
+workaround `nbformat`+`nbconvert`.
+
+---
+
 # 0050 — `jupyter_exec` falla por cliente colaborativo (workaround documentado)
 
 ## APP Metadata

dev/issues/completed/0052-footprint-aurgi-extraction.md

@@ -1,9 +1,29 @@
 ---
 title: "Extracción masiva de footprint_aurgi → registry"
-status: in_progress
+status: completed
 created: 2026-05-04
+completed: 2026-05-05
 ---
 
+## Cierre (2026-05-05)
+
+Los 9 batches completos: 41 funciones + 4 tipos + app `footprint_geo_stack` + 4 pipelines.
+Tests: 240 pasan, 2 skip esperados (1 por `osm2pgsql` ausente, 1 por geo stack no
+relanzable sin `.env` con `VALHALLA_DATA_DIR`).
+
+Bugs encontrados y arreglados al cerrar el issue:
+
+1. `setup_geo_stack_docker_pipeline` abortaba `verify` si `docker compose up -d` fallaba.
+   Ahora corre verify aunque el `up` falle (caso típico: stack ya vivo, lanzado con su
+   `.env` en otra parte).
+2. El check de PostGIS usaba el nombre `footprint_postgis` que no coincide con el
+   `container_name: better_maps_postgis` del compose. Corregido + credenciales reales
+   (`-U geoserver -d gis`).
+
+Función primitiva añadida como subproducto: `docker_container_running_py_infra` con
+tests unitarios + integración (7 tests, todos pasan). Reutilizable para cualquier
+verificador de stack.
+
 # 0052 — Extracción de funciones de `sources/footprint_aurgi/`
 
 Extracción de 45 funciones + 4 tipos del proyecto interno `footprint_aurgi` (código propio Aurgi, sin LICENSE — `source_license: internal-aurgi`).