[feature][P2] Declarar cobertura parcial no artefato quando o scan não cobriu o estate inteiro

[FabioLeitao]

Contexto

Hoje o produto tem duas formas de sinalizar que a saída não é plena confiança:

• -alpha / tinted (core/runtime_trust.py, core/integrity_anchor.py) — sinaliza integridade
  do build ("esse binário foi adulterado").
• dbtrial + dbmaxrows + watermark — sinaliza licença de trial ("relatório limitado por POC").

Falta um terceiro eixo, ortogonal aos dois: cobertura. Não existe hoje como dizer, na cara da
evidência, "este relatório analisou X de um estate medido em Y".

Por que importa

Um relatório que parece completo mas cobriu só parte do estate é o pior modo de falha do
produto — é garantia falsa de conformidade, exatamente o que o invariante de correção proíbe
(o piso pode degradar em capacidade e velocidade, nunca em correção; devolver menos verdade em
silêncio é violação). E é o cenário mais provável em uso real: alvo inacessível, credencial que
expirou no meio, container sem permissão, share que sumiu — hoje isso vira, na melhor hipótese, uma
linha de log que ninguém lê.

O Safe-Hold já cobre o caso de parar ("não continua com evidência insuficiente"). O que falta
é o caso em que a varredura terminou, produziu resultado útil, mas não foi exaustiva — aí
não se deve parar, deve-se declarar.

Pedido

1. Campo de cobertura no artefato — na aba Report info do Excel e no
   --export-audit-trail, algo como:
   {targets_configured, targets_completed, targets_failed, objects_seen, bytes_seen, coverage_note}.
2. Declaração legível quando targets_completed < targets_configured ou quando um alvo
   terminou com erro: uma frase no relatório, não só no log.
3. Enumerar o que ficou de fora — qual alvo, e por quê (inacessível / auth / permissão /
   timeout). "Evidence, not legal conclusion": o produto relata o buraco, não julga.
4. Nunca inferir completude — ausência de erro ≠ cobertura total. Se o produto não consegue
   afirmar que cobriu tudo, o campo deve dizer desconhecido, não completo.

Relação com o eixo de volume (contexto, não dependência)

Há trabalho comercial em curso (#1756, #1760) sobre footprint mapeado. Se um teto de volume vier a
existir, o mecanismo de declaração desta issue é o que impede que "estourou o teto" vire "relatório
silenciosamente menor". Mas esta issue não depende disso — o valor existe sozinho, hoje, para
alvo inacessível e falha parcial, que já acontecem.

Critérios de aceite

• Criar docs/plans/PLAN_COVERAGE_DECLARATION.md com <!-- plans-hub-summary: ... -->.
• Executar python scripts/plans_hub_sync.py --write.
• Adicionar entry em docs/plans/PLANS_TODO.md.
• Campo de cobertura no Excel (Report info) e no export do audit trail.
• Teste: alvo inacessível → relatório declara cobertura parcial e nomeia o alvo.
• Teste: todos os alvos OK → declara cobertura completa (e só nesse caso).
• Documentado em docs/REPORTS_AND_COMPLIANCE_OUTPUTS.md (+ pt_BR).
• Ortogonalidade preservada: cobertura não se mistura com -alpha (integridade) nem com
  dbtrial (licença) — três eixos, três campos.

---

Aberta por Claude (auditor externo, READONLY neste repo — só gh issue create/comment).
Origem: conversa de arquitetura com o operador em 2026-08-25.