[FEAT] Piloto: resolver o environment e fechar as cinco medições

[cpenaforte-clickbus]

User story

Como responsável pelo rollout, eu quero rodar o worker em paralelo com o agente local por uma semana,
para resolver a única pergunta em aberto do desenho e fechar as cinco medições antes de ligar o
schedule.

A pergunta em aberto, que fecha no primeiro run

• Confirmar em qual repositório o environment declarado no worker resolve — o do caller ou o do
  workflow chamado. A documentação do GitHub não fixa isso, e o modelo de secrets da §8 depende dele.
  A doc só diz: "If you include environment in the reusable workflow at the job level, the
  environment secret will be used, and not the secret passed from the caller workflow."

As cinco medições

• Paridade: metrics.json do worker contra execução local nos mesmos repositórios e no branch
  padrão, campo por campo, pelo comparador. É critério de bloqueio (§7) — divergência aqui muda o
  histórico do produto em silêncio.
• Maior idade de análise por uma semana, que fixa o threshold do watchdog e substitui o palpite de 30 h
• Leitura de refs dentro do runner, contra os 29,7 s medidos fora dele
• Tempo do push por repositório, com a resolução de identidade do active_users dentro — é o termo
  que a tabela de custo da §3.5 não cobre, porque as medições cronometraram a análise e não o push
• Tempo de ciclo com 2 vCPU, que confirma se o gargalo continua sendo rede

Como

Por workflow_dispatch, com o agente local ainda ligado. Nada é desligado nesta fase.

Acceptance criteria

• As cinco medições registradas com o comando que as regenera
• A resolução do environment documentada em docs/DECISIONS.md
• Threshold do watchdog fixado com número medido, substituindo as 30 h provisórias
• Paridade satisfeita — ou, se divergir, a causa identificada antes de qualquer rollout

Timebox

Uma semana de execução em paralelo.

Se encaixa em qual estágio?

Stage 2 — validação antes de mudar a fonte do dado do produto.

Links

• DD 0010 §6 (Fase 3) e §7: https://github.com/RocketBus/clickbus-rfc-design-docs/blob/main/design-docs/DD0010-Coleta-Centralizada-de-Atribuicao-do-Iris.md
• Parte de: Fases 3 e 5 — Piloto e rollout #212

O agente local durante o piloto

• Confirmar que os três caminhos locais seguem funcionando sem alteração e sem reinstalação:
  prepare-commit-msg, post_commit_push.sh e iris agent
• Confirmar a coexistência: um repositório pode receber, no mesmo dia e na mesma janela, uma análise
  local e uma do worker. Isso é histórico somado, não corrompido — a plataforma lê a execução
  mais recente por repositório e janela, e a cobertura conta o repositório como coberto por qualquer
  um dos dois.

Bloqueado por

O piloto só faz sentido com o worker inteiro de pé — é ele que está sendo medido:

• [FEAT] Ciclo: seleção, clone paralelo, análise e push #222 — o ciclo completo, que por sua vez fecha a Fase 1 inteira
• RocketBus/iris-actions#1 — o caller, porque o environment a confirmar é o dele
• RocketBus/billing#64 — o GitHub App, sem o qual não há credencial para cunhar

Não depende da Fase 4: o watchdog pode subir em paralelo, e o threshold que esta issue mede é
justamente o que vai configurá-lo.