chore(deps): atualiza packtools para 4.16.9 e bump para v0.3.0

[Rossi-Luciano]

O que esse PR faz?

Atualiza a dependência do packtools de 4.16.7 para 4.16.9 e faz o bump de versão do spsvalidator de 0.2.0 para 0.3.0, preparando o terreno para a i18n das mensagens de validação.

1. Bump do packtools (4.16.7 → 4.16.9): traz o PR Corrige a baseline da suíte de validação SPS packtools#1259 (correção da baseline da suíte de validação SPS), o PR fix: restaura a chave "text" em Abstract.data packtools#1261 (restaura a chave "text" em Abstract.data) e o PR Internacionaliza as mensagens das validações SPS packtools#1260 (internacionalização das mensagens de validação, fecha a issue Finalizar internacionalização (i18n) das mensagens de validação em packtools.sps.validation packtools#1257).
2. Bump de versão do spsvalidator (0.2.0 → 0.3.0), conforme combinado antes de gerar a próxima release/executáveis (issue Criar executável para Windows da release v0.2.0 #33).
3. Sincronização de locale packtools ↔ Flask-Babel: novo hook before_request (sync_packtools_locale em app.py) que chama packtools.sps.i18n.set_locale(...) a cada requisição, mapeando os códigos de idioma do spsvalidator (pt/en/es) para os nomes de diretório de catálogo do packtools (pt_BR/en/es).

Importante — limitação conhecida, com correção já encaminhada: o item 3 fica sem efeito prático por enquanto. A release 4.16.9 do packtools não inclui os catálogos .mo compilados quando instalada via git+https://... (forma como o spsvalidator consome a dependência) — o MANIFEST.in do packtools só empacota *.mo, mas o repositório só versiona os .po fonte, sem etapa de compilação no processo de instalação via git. Isso está documentado e reproduzido em scieloorg/packtools#1267 (aberta por pitangainnovare). Confirmei localmente: instalando packtools @ git+https://github.com/scieloorg/packtools@4.16.9 num venv limpo, packtools.sps.i18n.LOCALE_DIR nem existe, e set_locale("pt_BR") cai no fallback silencioso — mensagens continuam em inglês.

Já abri a correção upstream: scieloorg/packtools#1271 (fix/1267-package-locale-mo), que adiciona a etapa de build que faltava (compila os .po pra .mo antes de empacotar) e testei localmente que resolve o problema por completo. Assim que o #1271 for mesclado e uma nova tag for publicada — pelo padrão de numeração sequencial já usado (4.16.7 → 4.16.8 → 4.16.9), a expectativa é que seja 4.16.10 — este PR (ou um PR de acompanhamento, dependendo de quando a review terminar) precisa repinar o packtools pra essa nova versão antes da tradução funcionar de fato. O wiring do set_locale() adicionado aqui já está pronto e não deve precisar de nenhuma mudança quando isso acontecer, só o bump do pin em pyproject.toml.

Onde a revisão poderia começar?

• spsvalidator/pyproject.toml — bump das duas versões (packtools ainda em 4.16.9; repinar pra 4.16.10 assim que o packtools#1271 for mesclado e essa tag existir).
• spsvalidator/src/spsvalidator/app.py — hook sync_packtools_locale e o mapeamento _PACKTOOLS_LOCALE_MAP.
• spsvalidator/tests/test_packtools_locale_sync.py — testes do wiring (com set_locale mockado, já que o packtools ainda não traduz de fato nada instalado via git).
• spsvalidator/tests/test_packtools_validations.py — assertiva de versão atualizada.

Como este poderia ser testado manualmente?

1. pip install -e ".[dev]" pra garantir que o packtools 4.16.9 foi instalado (pip show packtools).
2. Rodar a suíte de testes (pytest) — a baseline de testes já falhando antes deste PR (falhas pré-existentes, não relacionadas a este bump) se mantém idêntica; nenhuma nova falha foi introduzida, exceto a assertiva de versão que já foi corrigida aqui.
3. Rodar spsvalidator --browser e conferir que o cabeçalho mostra SPSValidator-v0.3.0.
4. Validar um pacote SPS com Accept-Language diferentes (pt-BR, en-US, es-AR) e confirmar que a interface do spsvalidator continua traduzindo normalmente (esse PR não muda a i18n do spsvalidator em si, só prepara o lado do packtools).
5. Opcional, pra confirmar a limitação atual: instalar packtools @ git+https://github.com/scieloorg/packtools@4.16.9 num venv limpo e rodar python -c "from packtools.sps import i18n; i18n.set_locale('pt_BR'); print(i18n._('the record was not found'))" — o resultado continua em inglês (evidência de Release 4.16.9 não inclui catálogos .mo, fazendo set_locale() manter mensagens em inglês packtools#1267).
6. Depois que 4.16.10 (ou a tag que incorporar o packtools#1271) existir: repetir o passo 5 apontando pra essa tag — o resultado esperado passa a ser "o registro não foi encontrado" (tradução real).

Algum cenário de contexto que queira dar?

Esse PR nasce de uma combinação feita durante a revisão do PR #37 (issue #36): "depois em outro PR, vamos precisar atualizar o sps-validator para usar o packtools mais recente e colocar no sps_validator umas instruções para setar o locale (...) antes de criar a nova release do sps_validator e novos executáveis". Este é esse PR.

A i18n de fato só vai aparecer pro usuário final depois de duas coisas acontecerem, nessa ordem: (1) scieloorg/packtools#1271 ser mesclado e uma nova tag (esperada 4.16.10) ser publicada, e (2) o pin do packtools neste repositório ser atualizado pra essa tag. Recomendo não gerar novos executáveis/release do spsvalidator antes disso, pra não prometer uma tradução que ainda não funciona.

Quais são os tickets relevantes?

Relacionado a scieloorg/packtools#1257, scieloorg/packtools#1267, scieloorg/packtools#1271 (correção já aberta) e à issue #33 (executável Windows da próxima release).

Referências

• https://github.com/scieloorg/packtools/releases/tag/4.16.9
• Finalizar internacionalização (i18n) das mensagens de validação em packtools.sps.validation packtools#1257
• Release 4.16.9 não inclui catálogos .mo, fazendo set_locale() manter mensagens em inglês packtools#1267
• fix(packaging): compila os catalogos i18n antes do build (closes #1267) packtools#1271

---

Segurança da informação (NSI.04)

Este PR manipula dados sensíveis ou pessoais (LGPD)?

• Sim
• Não

Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?

• Sim
• Não

Este PR introduz, atualiza ou remove dependências de terceiros?

• Sim — atualiza o pin do packtools de 4.16.7 para 4.16.9 (mesma fonte git já usada, scieloorg/packtools, sem dependências novas). Vai precisar de outro bump pra 4.16.10 (ou equivalente) assim que fix(packaging): compila os catalogos i18n antes do build (closes #1267) packtools#1271 for mesclado.
  • Verificado e aprovado
  • Pendente / vulnerabilidade aceita com justificativa: repositório não tem SBOM/Trivy configurado; validação feita via changelog do packtools (releases 4.16.8/4.16.9) e suíte de testes local.
• Não

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

• Sim
• Não aplicável a este PR — repositório não tem pipeline de Sonar/Trivy configurado; validação feita via suíte de testes local.

Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?

• Sim
• Não — nenhuma mudança em rotas/templates/queries; o hook novo só passa um código de idioma fixo (de um mapa interno) pro packtools.

Este PR expõe novos endpoints, telas ou serviços?

• Sim
• Não — nenhuma rota nova.

Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?

• Não, nenhum segredo foi commitado
• Sim

[pitangainnovare]

Sugiro aguardar a solução dessa issue aqui: scieloorg/packtools#1267

E entao gerar a packtools 4.16.10
E então espetá-la aqui no spsvalidator