Generation pendente não tem reaper, e prende o card em "em geração"

[davidbenal]

Levantado ao fechar a Etapa 1 do Crystal Ball (Linear PROD-2127, PR #16).

O passo reason cria a linha em generations antes de executar, de propósito: é o que faz o card acender "em geração" no kanban durante uma espera longa de motor (o primeiro passo do Crystal Ball leva de 100 a 240 segundos). O passivo é direto: se o processo morrer no meio, a linha fica pending para sempre.

deriveColumn (web/lib/queries.ts:281, 308 do repo do Workbench) prende o card em "em geração" enquanto houver generation pending ou running, e não há saída. failStaleRuns (web/lib/runs.ts:166) cobre só app_runs, e cleanup_engine._scan_failed_generations (lib/cleanup_engine.py:217-232) só varre status='failed'.

Não morde no Eco, cujo passo reason é template instantâneo. Morde no Crystal Ball.

Caminho: varredura de generation pending com created_at velho, marcando failed com motivo, junto ou separado do reaper de run pausada.

[davidbenal]

Resolvido em 37ec210, na PR #27 (Trilha A da Etapa 3 / PROD-2129). Fecha quando a PR mergear.

Varredura mecânica, não política — não decide nada sobre a run, só constata que a linha não tem mais quem a feche:

1. generation pending cuja run NÃO está running (não depende de relógio: a run já terminou, então nenhum processo vivo vai fechá-la). O motivo gravado nomeia a run e o status em que ela ficou.
2. generation pending mais velha que --horas (default 6), que é a rede para a run que ficou running órfã.

Dois pontos de entrada: studiolocal runs reap [--horas N] [--json] e uma chamada no início de cada run (dois UPDATEs indexados por status). --horas 0 é recusado: seria datetime('now') e mataria a generation que acabou de nascer.

O teste que mais importa é o do vizinho que continua passando (tests/test_reaper.py::test_nao_encosta_no_passo_em_curso): uma generation recém-criada sob uma run running é exatamente o passo que está executando agora, e o reaper tem de deixá-la em paz. Sem esse caso, "o reaper fecha tudo" imitaria "o reaper funciona".

[davidbenal]

Fechada com verificação por leitura de código na main (e939f26), não por dedução.

O que confere:

• Tracker.reap_stale_generations existe (lib/tracker.py:708) e faz a varredura por dois critérios: generation pending cuja run chegou a status terminal (STATUS_TERMINAIS), e generation pending mais velha que --horas (default 6).
• Exposto como comando: studiolocal runs reap (lib/cli.py:1664-1701), com piso de --horas >= 1 para não ceifar linha recém-nascida.
• Roda sozinho no início de toda run (lib/cli.py:1242), que é o momento mais barato de varrer.
• O caminho por IDADE também encerra a run como failed, que é o que solta o card: deriveColumn do Workbench prende em em_geracao enquanto running > 0 || run_active || workflow_running (web/lib/kanban-column.ts:89), e com a generation failed e a run terminal nenhum dos três termos vale.
• Testes: tests/test_reaper.py, incluindo o vizinho que continua passando (run em execução não é alcançada) e o controle de que a run running órfã é encerrada junto.

O defeito descrito, linha pending para sempre e card sem saída, não acontece mais.

PROD-2129, Etapa 3 do Crystal Ball, PR #27.