sh: el trap del subshell, reportado — y la lección de que upstream ya lo tenía en sus PRUEBAS

brush#1396 abierto. Antes de escribirlo apareció que reubeno/brush ya marcaba
el fallo como known_failure en trap.yaml:226 (y :269, :323 para las otras dos
variantes), sin issue que lo siguiera.

Queda anotado porque es método, no anécdota: un known_failure en la suite del
candidato es evidencia de primera y cuesta un gh api mirarla. Buscar en las
PRUEBAS del candidato, no sólo en sus issues, antes de decir «hallazgo nuevo».

Lo que el reporte sí aporta sobre esos TODOs: que las tres variantes son
probablemente un mismo bug (on_exit() sólo lo llaman los puntos de entrada de
nivel superior; el subshell de interp.rs:662-683 clona el shell y devuelve el
exit code sin pasar por ahí), que también pega en pipeline y en segundo plano,
y que falla en silencio con rc intacto.

scripts/fixtures/sh-casos/08-trap-exit-y-estado.sh

@@ -1,4 +1,6 @@
 # `trap ... EXIT` + el estado de salida propagado: lo usan los scripts de la granja para limpiar.
+# Destapó reubeno/brush#1396: brush NO ejecuta nunca el trap EXIT de un subshell, en silencio y con
+# rc intacto. Upstream lo tenía marcado `known_failure` en trap.yaml:226 sin issue abierto.
 trap 'echo "trap-exit rc=$?"' EXIT
 ( trap 'echo "trap-subshell"' EXIT; true )
 false