[P2][chore][ci] PRs do agente de nuvem do Cursor nascem bloqueadas: commit assinado com chave desconhecida (unknown_key) #2009

Sintoma

PRs abertas pelo agente de nuvem do Cursor (app/cursor) nascem com o commit assinado por uma chave que
o GitHub não reconhece. O ruleset do main exige required_signatures, então a PR fica BLOCKED até o
operador re-assinar o commit à mão e dar force-push.

Evidência (via gh api, 2026-09-28)

Não é regressão nova, é trabalho repetido. As 5 PRs anteriores do app/cursor tiveram pelo menos 1
head_ref_force_pushed cada: #1716 (5), #1764, #1847, #1924, #1955 (1 cada). Todas terminaram com head
verified=true. Isso é consistente com re-assinatura manual em todas. Só confirmei o caso do #2008; nas
outras, é inferência a partir do timeline.

Mesma classe de problema (já resolvida pra outros bots)

• [P2] dependabot-sync.yml cannot push under required_signatures ruleset #1419 / ci(deps): Regenerate requirements.txt auto-push incompatible with required_signatures #1580: dependabot-sync e o auto-push do requirements.txt barrados por required_signatures.
• chore(security): auditar e aplicar required_signatures em TODOS os rulesets DataBoar (2 unsigned barrados no #55 do site) #1479: auditoria de required_signatures em todos os rulesets.
• [ADR] Branch protection canônico pra mantenedor solo — bypass admin restrito a pull_request-mode (generalização de maestro#41) #1566: ADR de branch protection pra mantenedor solo.

Opções (decisão do operador, não minha)

1. Manter a re-assinatura manual como gate deliberado e documentar o procedimento (recomendado).

   • A assinatura do operador no head é a atestação humana de que ele leu o que o agente fez.
   • Esse é o sentido do required_signatures num repo de mantenedor solo.
   • Hoje o passo existe, mas só na cabeça do operador.
   • Custo: um runbook curto em docs/ops/ com o passo-a-passo:
     • git worktree add isolado;
     • git commit --amend --no-edit -S para 1 commit, ou git rebase --exec 'git commit --amend --no-edit -S' origin/main para vários;
     • git push --force-with-lease;
     • remover o worktree.
   • Opcional: um script wrapper que só executa esse passo declarado.

2. Registrar a chave do agente de nuvem como signing key na conta do operador.

   • Resolve o bloqueio.
   • Mas o "Verified" passa a significar "o operador ou o agente" sob a mesma identidade.
   • O selo de assinatura deixa de distinguir autoria humana de autoria de agente.
   • Não recomendo, pelo mesmo motivo que o ruleset existe.

3. Identidade própria de bot pro agente: conta ou app separado, com chave registrada nele.

   • O "Verified" mostra quem de fato escreveu.
   • A atestação humana fica no review/merge.
   • Esbarra no problema de mantenedor solo da [ADR] Branch protection canônico pra mantenedor solo — bypass admin restrito a pull_request-mode (generalização de maestro#41) #1566: não há segundo revisor.
   • Vale avaliar junto com aquela ADR, não isoladamente.

Critério de aceite (se a opção 1 for escolhida)

• Runbook em docs/ops/ descrevendo a re-assinatura de PR do agente de nuvem, com o porquê: atestação humana, não burocracia.
• Link do runbook a partir do doc de branch protection/rulesets existente (confirmar o caminho com git grep -n required_signatures docs/).
• Nenhuma alteração no ruleset.

Refs #2008