fix(examples): mesma correcao de log nos tres demos que ainda usam :latest (core#135, preventivo)

[fabianocruz]

Continuacao do #136, que aplicou isto nos quatro validate.sh dos jobs vermelhos. Aqui vao os tres restantes: pix-nfse-skeleton, nfse-from-natural-language e whatsapp-installment-negotiation.

Por que mexer no que esta passando

Estes tres jobs estao verdes por contingencia, nao por estrutura. Eles carregavam exatamente o mesmo docker run -d --rm dos quatro que quebraram. A unica diferenca e qual imagem puxam, e isso e configuracao, nao desenho:

jobs	imagem	criada	User
os 4 que ficaram vermelhos	ghcr.io/codespar/codespar:main	2026-08-22	node (uid 1000)
estes 3	ghcr.io/codespar/codespar:latest (default)	2026-05-31	vazio = root

O :latest passa porque e de maio, roda como root e e anterior a mudanca que fez o runtime exigir um diretorio de estado onde possa escrever. Ele nao passa porque esta certo; passa porque esta velho.

No dia em que alguem mover estes tres para a imagem atual — e mover para a imagem atual e o comportamento desejado, nao um acidente — eles falham igual e sem diagnostico nenhum, e a pessoa que pegar redescobre a core#135 do zero. Custa a mesma mudanca que ja foi validada quatro vezes.

Este PR e preventivo. Nao ha job vermelho aqui para consertar.

O que mudou

Identico ao #136, ja verificado em CI real:

• docker run -d --rm vira docker run -d. O container que morre no startup para de levar o proprio log junto.
• cleanup_docker remove o container explicitamente, ja que o --rm saiu.
• docker rm -f defensivo antes do docker run, contra orfao de execucao morta com SIGKILL (o nome usa $$).
• Caminho de timeout: alem do docker logs, imprime docker inspect (status, exit code, OOM) e o tail -n 20 do $RUNTIME_LOG.
• Caminho de falha do docker run: imprime o arquivo em vez de pedir para alguem abrir um arquivo num runner efemero.

O pix-nfse-skeleton nao usa aimock, entao o cleanup_docker dele nao tem stop_aimock; fora isso a mudanca e a mesma. Depois deste PR as linhas de docker sao byte-identicas nos sete validate.sh (mesmo hash do bloco).

$ grep -rn "docker run -d --rm" examples/*/scripts/validate.sh
  nenhum

Verificacao

bash -n limpo nos tres. Nao da para rodar o validate.sh inteiro localmente: macOS traz bash 3.2, que sob set -u engole o … multibyte depois de $AIMOCK_PORT; CI roda ubuntu com bash 5.

O controle deste PR e o oposto do controle do #136. La eu precisava que a falha passasse a se explicar. Aqui eu preciso que o caminho feliz continue feliz: os tres jobs tem que permanecer verdes. Se o docker run tivesse quebrado, ficariam vermelhos; se o cleanup_docker tivesse quebrado, o container vazaria. Comento com o resultado do CI.

Refs core#135. Itens 2 e 3 da issue seguem abertos e sem dono.

[fabianocruz]

Controle verificado: o caminho feliz continua feliz

O CI rodou. Os tres jobs que este PR toca continuam verdes, e verdes pelo motivo certo — o container sobe e responde:

validate-example-skeleton:                        starting runtime from ghcr.io/codespar/codespar:latest … runtime up after 2s
validate-example-nfse-from-natural-language:      starting runtime from ghcr.io/codespar/codespar:latest … runtime up after 2s
validate-example-whatsapp-installment-negotiation: starting runtime from ghcr.io/codespar/codespar:latest … runtime up after 2s

Era esse o controle que faltava. O #136 precisava provar que a falha passa a se explicar; este precisa provar que a mudanca nao quebra o que passava. Se o docker run tivesse quebrado, os tres ficariam vermelhos; se o cleanup_docker tivesse quebrado, o container vazaria em vez de ser removido. Nenhum dos dois aconteceu, e o runtime up after 2s confirma que o container realmente subiu, em vez de o job passar por algum atalho.

Os quatro vermelhos do rollup sao os mesmos pre-existentes da core#135, intocados por este PR.

SUCCESS  ci
SUCCESS  gitleaks
SUCCESS  validate-example-skeleton                          <- tocado aqui
SUCCESS  validate-example-nfse-from-natural-language         <- tocado aqui
SUCCESS  validate-example-whatsapp-installment-negotiation   <- tocado aqui
FAILURE  validate-example-payment-failure-triage             \
FAILURE  validate-example-boleto-expiry-fiscal-remediation    | os 4 da core#135,
FAILURE  validate-example-service-invoice-meta-tool           | nao tocados aqui
FAILURE  validate-example-installment-negotiation-meta-tool  /