feat: CFOP/IPPT write-capability core (inert, not wired, not activated)

Missao 3 / Bloco C.1-C.2: new agent/src/gti_fiscal_agent/cfop_ippt_auto_apply.py
mirrors the existing rtc_auto_apply.py safety model for a new, narrower
capability (CFOP_IPPT_WRITE_V1): compare-before-write, stale-write guard
("human override sempre vence" - a value changed since the candidate was
selected is never overwritten), one transaction per cell, readback
verification, and rollback that only restores a value still equal to what
was written. Candidates come exclusively from field_contract.resolve_product's
own AUTO_FILL_SAFE classification for CFOP/IPPT - no new fiscal rule.
14 new tests (agent/tests/test_cfop_ippt_auto_apply.py) prove: flag OFF means
the caller never reaches a write; only CHANGE+write_eligible CFOP/IPPT cells
become candidates; a human edit between decision and write blocks the write;
a second run over an already-applied cell writes zero; a technical failure on
one cell never stops the batch; rollback refuses when the value changed again.

Deliberately NOT wired into agent/scripts/run_agent_service.py::execute_job,
and the Hub-side authorization/audit plumbing (Installation.cfop_ippt_write_mode,
audit table, job-delivered authorization - the same pattern as
central/app/rtc_audit.py) does not exist yet. No currently-published Agent
behavior (1.3.8) changes with this commit - nothing imports this new module.
See docs/CFOP_IPPT_WRITE_CAPABILITY_V1.md for the acceptance roteiro (test
products only, never real ones) and what remains before this can ever be
activated for a real installation - deliberately left for review before any
further step, per this mission's explicit instruction not to publish it active.

Also: dossie_contador.md (internal + anonymized) updated with the Bloco B
finding that the ~9.5% CST=01 anomaly is confined to a single calendar month
(not the whole year), with no fiscal-dimension (NCM/CFOP/CSOSN/ICMS group)
explaining which items got it - consistent with a one-off technical event,
not a deliberate rule.

REAL_PRODUCT_FISCAL_WRITES=0 (no write path exists in this commit).

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

central/static/docs/dossie_contador.md

@@ -19,13 +19,16 @@ operação" ou um perfil fixo por empresa. **Libera**: card "Perfil de PIS/COFIN
 ## (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.
+e são exclusivamente de um único mês (dezembro de um ano específico), não do ano inteiro: 90,9%
+dos itens daquele mês têm o campo preenchido, todos os outros meses (incluindo o resto do mesmo
+ano) têm 0%. Testamos se o NCM, o grupo do produto, o CFOP ou o código de ICMS do item explicam
+quais itens recebem o valor: não há uma fórmula fiscal por trás — é um conjunto pequeno e
+homogêneo de vendas reais concentrado nesse único mês, que 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 fiscal deliberada** — é um efeito técnico de um evento pontual (ex.:
+uma migração de dados ou uma versão diferente do software de emissão usada só naquele mês). Não
+decidimos isso por evidência insuficiente para confirmar a causa exata; a pergunta é se o contador
+reconhece esse episódio.
 
 ## (c) CFOP_ENTRADA no cadastro do produto é necessário ou é sempre definido na nota de compra?