sergio/takana

La v0.5 dejó dicho que faltaba probar que una petición hecha en «Banco» sale
por el proxy de «Banco». Se intentó y no se llegó; queda escrito el intento
porque el muro es reusable y el que venga después no tiene por qué volver a
descubrirlo.

El diseño de la prueba sirve y no necesita red ni servidor: la MISMA url a un
puerto vacío desde dos contenedores, y comparar los errores. `connectionFailure`
contra `proxyConnectFailure`. Que sean DISTINTOS es la prueba, porque el segundo
sólo aparece si Gecko habló con un proxy y el único que se lo pudo indicar es
nuestro proxy.onRequest mirando el cookieStoreId.

Lo que falta es abrir una pestaña EN un contenedor, y las tres puertas están
cerradas:

1. Desde la línea de comandos no existe el flag.
2. Marionette SÍ está en el artefacto y responde —se le habló con un cliente
   propio de 60 líneas, el protocolo es `<longitud>:<json>`, abrió sesión y
   aceptó comandos—, pero el contexto chrome exige `-remote-allow-system-access`
   y en la jaula no lo tomó ni por bandera, ni con --remote-debugging-port, ni
   por MOZ_REMOTE_ALLOW_SYSTEM_ACCESS=1, que es lo que RemoteAgent.sys.mjs lee
   en su constructor. Comprobado que la variable llega al proceso.
3. Desde la extensión, `tabs.create({cookieStoreId})` exige el permiso
   `cookies` (ext-tabs-base.js:getUserContextIdForCookieStoreId). Darle a la
   extensión del proxy acceso a TODAS las cookies del usuario para poder
   probarse a sí misma sería pagar con la superficie de ataque del producto una
   comodidad del test. No se hace, y queda dicho por qué.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ

diff --git a/docs/26-atuq-envoltorio-gecko.md b/docs/26-atuq-envoltorio-gecko.md
index 587eefdf..0cd5dc82 100644
--- a/docs/26-atuq-envoltorio-gecko.md
+++ b/docs/26-atuq-envoltorio-gecko.md
@@ -361,8 +361,38 @@ Corriendo el árbol de atuq en la misma jaula que usa `scripts/atuq-nested.sh`:
 | Los guardianes del cruce política↔XPI FALLAN cuando deben | `scripts/test-atuq-politica.py`: 5 formas de romperlo, las 5 matan el build, y el control con la política intacta pasa |
 
 **Lo que NO está probado, dicho por su nombre:** que una petición hecha en el contenedor «Banco»
-salga por el proxy de «Banco». Eso pide automatizar la UI —una pestaña de contenedor no se abre
-desde la línea de comandos— y queda pendiente en vez de darse por hecho.
+salga por el proxy de «Banco». Se intentó y **se documenta el intento**, porque el que venga después
+no tiene por qué volver a descubrir el muro.
+
+El diseño de la prueba está bien y no necesita red ni servidor: se pide la MISMA url —un puerto
+donde no hay nadie— desde dos contenedores y se comparan los dos errores. Sin proxy tiene que dar
+`about:neterror?e=connectionFailure`; con el proxy de «Banco» apuntando a un puerto cerrado tiene
+que dar `e=proxyConnectFailure`. **Que los códigos sean DISTINTOS es la prueba**: el segundo sólo
+aparece si Gecko intentó hablar con un proxy, y el único que se lo pudo indicar es nuestro
+`proxy.onRequest` mirando el `cookieStoreId`. El control sin proxy no es decorativo — sin él, dos
+fallos podrían ser el mismo fallo.
+
+Lo que falta es **abrir una pestaña EN un contenedor**, y las tres puertas están cerradas:
+
+1. **Desde la línea de comandos, no existe.** No hay flag para el `userContextId` de la pestaña
+   inicial.
+2. **Marionette SÍ está en el artefacto** (`chrome/remote/content/marionette/` en `omni.ja`) y
+   responde: se le habló con un cliente propio de 60 líneas —el protocolo es `<longitud>:<json>`—,
+   abrió sesión y aceptó comandos. Pero abrir una pestaña de contenedor pide **contexto chrome**, y
+   eso exige `-remote-allow-system-access`; en esta jaula NO lo tomó ni por bandera, ni combinado
+   con `--remote-debugging-port`, ni por la variable `MOZ_REMOTE_ALLOW_SYSTEM_ACCESS=1` que el
+   propio `RemoteAgent.sys.mjs` lee en su constructor (comprobado que la variable llega al proceso).
+   Queda como cabo suelto medido, no como suposición.
+3. **Desde la extensión tampoco, y por una razón de diseño que conviene NO saltarse:**
+   `tabs.create({cookieStoreId})` exige el permiso `cookies` — está en
+   `ext-tabs-base.js:getUserContextIdForCookieStoreId`, que lanza `No permission for cookieStoreId`
+   sin él. Agregarle a la extensión del proxy un permiso sobre TODAS las cookies del usuario para
+   poder probarse a sí misma sería pagar con la superficie de ataque del producto una comodidad del
+   test. No se hace.
+
+Así que el camino que queda es el (2) con el `allowSystemAccess` resuelto, o una prueba desde el
+lado del sistema (mirar el `connect()` con `strace` sobre el proceso). Ninguno de los dos entra en
+esta unidad.
 
 **Dos obstáculos del método, que valen para la próxima:**