feat: audited-decision gate for PIS/COFINS and CFOP_ENTRADA NOT_APPLICABLE/OPERATION_TIME

Missao 2 (fechamento de lacunas fiscais, read-only + UI/engine gated):
- field_contract: pis_cofins_profile now also accepts the literal sentinels
  NOT_APPLICABLE/OPERATION_TIME, resolving to NA only from an audited
  FiscalContextEntry - never inferred from emission statistics. CFOP_ENTRADA
  under an already-decided entry_scope=MIXED_OR_DYNAMIC now resolves to NA
  instead of MANUAL, so it stops blocking product completeness and stops
  re-asking an already-answered question. Regression tests prove: no ADMIN
  decision => unchanged old behavior; decision present => gated bucket, no write.
- context_keys: validate_entry accepts the two sentinels for pis_cofins_profile.
- Contexto Fiscal UI: PIS/COFINS and CFOP_ENTRADA cards show the Bloco 2
  cross-database evidence (5 installations, CRT 1 and 3: emission never reads
  the PIS/COFINS cadastral fields anywhere) and a link to an ADMIN-facing,
  anonymized dossie-for-the-accountant; entry_scope is now a dropdown.
- release/tests: decoupled the Hub's GTI_FISCAL_VERSION from the Agent's own
  version (test_versions_are_coherent_across_hub_and_packages vs the new
  test_agent_version_is_internally_coherent) - a Hub-only release must not
  require touching, rebuilding or republishing the Agent.
- New read-only evidence: docs/runs/GTI_dryrun_universe_summary.json (527
  products, Agent 2's real database), docs/runs/BLOCO2_PIS_COFINS_CROSS_DB_V1.json
  (5 installations), docs/fiscal_completeness_matrix.md, docs/dossie_contador.md
  (internal, real names) + central/static/docs/dossie_contador.md (public,
  anonymized - no CNPJ/razao social/product names), docs/AGENT2_UPGRADE_RUNBOOK_V1.md.
- CLAUDE.md: recorded the permanent fiscal-mission rules (no AI/scraping, no
  Firebird schema changes, deploy only via deploy_hub.ps1, never reenroll,
  no remote access to client Agent hosts, no client data in unauthenticated
  static routes).

No schema/migration change. Zero Firebird writes (new scripts never open a
write connection). Hub only - Agent code untouched.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

central/static/docs/dossie_contador.md

@@ -0,0 +1,68 @@
+# Dossiê para o contador (2026-09-28)
+
+Este documento não afirma nenhuma regra fiscal. Cada pergunta mostra a evidência real medida
+(somente leitura, sem gravação em nenhum banco) e qual clique na tela "Contexto Fiscal" do painel
+a resposta libera. Identificadores de cliente foram substituídos por rótulos genéricos
+(Cliente A–E); nenhum nome de produto, CNPJ ou razão social aparece aqui.
+
+## (a) Em CRT=1, o PIS/COFINS por item segue o cadastro do produto ou a operação/regime?
+
+**Evidência**: em 5 instalações auditadas (Cliente A, CRT 1; Clientes B/C/E, CRT 1; Cliente D,
+CRT 3), o cadastro do produto **nunca** tem os campos de PIS/COFINS usados pela emissão: mesmo
+quando a nota fiscal emitida traz um CST de PIS/COFINS preenchido, o cadastro está em branco para
+o mesmo produto (23 casos confirmados no Cliente A). Nos Clientes B, C, D e E, a emissão nunca
+preenche o CST de PIS/COFINS (0% dos itens, em todos os anos de histórico disponíveis). Isso indica
+que a emissão não lê o cadastro — mas não decide se o valor correto é "não aplicável", "por
+operação" ou um perfil fixo por empresa. **Libera**: card "Perfil de PIS/COFINS" → escolher
+`NOT_APPLICABLE`, `OPERATION_TIME` ou um perfil JSON de 6 campos.
+
+## (b) O CST 01 emitido em ~9,5% dos itens é intencional?
+
+**Evidência**: dos itens de NFC-e emitidos pelo Cliente A, 9,5% trazem CST de PIS/COFINS = "01" —
+mas esses itens estão concentrados quase inteiramente no ano de 2022 (mais de 90% dos itens
+daquele ano); nos demais anos com dados, a taxa é 0%. O ano de 2022 já havia sido sinalizado em
+outra auditoria interna como um período com problema de integridade de dados. A leitura mais
+provável é que **não é uma política atual deliberada** — é um comportamento isolado de um período
+específico, possivelmente uma versão antiga do software de emissão ou uma configuração temporária.
+Não decidimos isso por evidência insuficiente para confirmar a causa exata; a pergunta é se o
+contador reconhece esse padrão de 2022.
+
+## (c) CFOP_ENTRADA no cadastro do produto é necessário ou é sempre definido na nota de compra?
+
+**Evidência**:
+- **Schema do banco**: a coluna é opcional no próprio banco de dados (sem obrigatoriedade, sem
+  valor padrão, sem regra de validação) — o sistema nunca exige um valor aqui a nível de banco.
+- **Uso real é muito diferente entre clientes**: em dois clientes o campo está praticamente sempre
+  em branco; em outros três está preenchido em quase 100% dos produtos, com valores plausíveis —
+  ou seja, alguns clientes efetivamente mantêm esse cadastro, outros não.
+- Isso mostra que não existe uma regra universal: depende de como cada loja opera. Por isso o motor
+  já trata isso como uma decisão por instalação (`entry_scope`), nunca uma regra fixa do sistema.
+- **Não verificado ainda** (requer acesso à tela de entrada de nota do sistema, que não fizemos):
+  se a tela de lançamento de nota de compra lê o CFOP_ENTRADA do cadastro como sugestão inicial, ou
+  sempre pede a digitação manual. Roteiro de 5 passos para teste manual:
+  1. Anote o CFOP_ENTRADA atual de um produto de teste (ou deixe em branco).
+  2. Abra o cadastro do produto e grave um CFOP_ENTRADA diferente (ex.: 1102).
+  3. Lance uma nota de entrada (compra) desse mesmo produto.
+  4. Veja se o CFOP do item da nota já vem preenchido com o valor do cadastro, ou em branco.
+  5. Repita com CFOP_ENTRADA em branco no cadastro e confirme se a nota exige digitação manual.
+- **Libera**: card "CFOP de entrada padrão" → `INTRA`, `INTER` ou `MIXED_OR_DYNAMIC` (este último
+  não bloqueia mais a completude do produto).
+
+## (d) O que mais o levantamento deixou como decisão pendente com evidência insuficiente?
+
+- **Origem da mercadoria** (nacional/importado): nenhuma fonte automática existe para decidir isso
+  — a grande maioria dos produtos não tem nenhuma evidência. Só pode ser respondido produto a
+  produto ou por grupo, nunca por uma regra geral.
+- **Tratamento de ICMS** para um pequeno grupo de produtos cujo código fiscal está em branco —
+  parte é cadastro de teste/incompleto, mas alguns produtos reais também aparecem.
+- Um pequeno número de produtos com o código fiscal (CSOSN) em branco hoje. Nenhuma simulação
+  escreve nada; um valor padrão só se aplica de fato após a confirmação do "Tratamento padrão de
+  ICMS" no card correspondente, e mesmo assim o motor consulta o tratamento antes de propor o
+  código (nunca aplica um padrão cegamente).
+
+## Como usar este dossiê
+
+Cada resposta é dada uma única vez, no painel ("Contexto Fiscal", aba do Agent), nunca escrevendo
+nada no ERP diretamente — a decisão fica registrada e auditada, e só depois disso o motor passa a
+considerar o campo resolvido (ou explicitamente não-bloqueante). Nenhuma decisão aqui é assumida
+por padrão.