chore: sincroniza bounds de setup.py/tox.ini com o que foi testado (fase 8, #1251)

[Rossi-Luciano]

O que esse PR faz?

Fase 8, última da estratégia de atualização de dependências definida na issue #1251: sincroniza os pisos soltos de setup.py e tox.ini com as versões já validadas nas fases 1-7, e corrige um bug real na descoberta de testes do tox.ini.

setup.py

INSTALL_REQUIRES atualizado para os pisos testados: aiohttp>=3.14.3, langcodes>=3.5.1, Pillow>=12.3.0 (antes sem nenhum piso), requests>=2.34.2, python-docx>=1.2.0, tenacity>=8.5.0. TESTS_REQUIRE: python-magic>=0.4.27 (antes sem piso).

lxml (fase 4, #1283) e charset-normalizer em TESTS_REQUIRE (fase 5, #1284) não foram tocados aqui de propósito: já têm PR próprio em andamento, evita conflito/duplicação.

tox.ini

• Fator lxml492 mantido (também pertence ao fix(security): bump lxml para 6.1.1, corrige XXE de leitura de arquivo local (fase 4, #1251) #1283).
• charset-normalizer<3.0 → charset-normalizer (sem cap), mesma correção da fase 5 que faltou aplicar em tox.ini na época.
• scielo_scholarly_data fixado em @v0.1.4, mesma correção da fase 7 (chore: fixa scielo_scholarly_data na tag v0.1.4 (fase 7, #1251) #1286) que faltou aplicar em tox.ini na época.

Correção real encontrada durante a investigação (não é sobre Pillow)

Investigando a fundo antes de aplicar a mudança, descobri que a premissa que eu vinha carregando desde a fase 1, de que "Pillow sem piso em setup.py é a causa raiz das falhas do tox", estava errada. Comparei a lista completa de falhas do tox com o baseline do pytest: são exatamente as mesmas 40 falhas pré-existentes (já documentadas na #1276), só contadas de forma diferente entre pytest e unittest.

A causa real dos "23 failures + 19 errors" (42, não 40) é um bug separado, sem relação com nenhuma dependência: python -m unittest -vvv sem argumentos faz descoberta ampla a partir da raiz do projeto e tenta importar packtools/sps/sps_versions/sps-1.9 e sps-1.10 (pacotes de dados de configuração legítimos, com hífen no nome) como se fossem módulos de teste, gerando 2 ERROR espúrios (unittest.loader._FailedTest / ModuleNotFoundError).

Corrigido trocando o comando para python -m unittest discover -s tests -t . -vvv, restringindo a descoberta ao diretório tests/ (o que python setup.py test já fazia antes, via test_suite='tests' em setup.py; esse comportamento se perdeu na migração mencionada no comentário ao lado do comando antigo).

Onde a revisão poderia começar?

tox.ini, o comentário explicando o fix do comando commands=. setup.py, os pisos de versão atualizados.

Como este poderia ser testado manualmente?

tox -e py310-lxml492

Antes desta correção: Ran 5975 tests, failures=23, errors=19. Depois: Ran 5973 tests, failures=23, errors=17 (40 no total), idêntico ao baseline do pytest (40 failed, 5973 passed, 30 skipped), sem nenhum ModuleNotFoundError para sps_versions.

Algum cenário de contexto que queira dar?

Independente das fases 1-7. Rodei o tox completo (não só unittest local) antes e depois da correção do comando para confirmar a mudança de comportamento real, não só uma amostra.

Esse achado corrige uma suposição que repeti nos corpos dos PRs #1280 a #1284 (que o tox mostrava mais falhas por causa do Pillow sem piso). Não é verdade: o tox sempre mostrou exatamente as mesmas 40 falhas pré-existentes da #1276, só que contadas com granularidade diferente pelo unittest. Peço desculpa pela imprecisão nos PRs anteriores; a causa real era este bug isolado de descoberta de testes, agora corrigido.

Screenshots

N/A (mudança de configuração de build/teste, sem interface).

Quais são os tickets relevantes?

Parte de #1251 (fase 8, última da estratégia de atualização de dependências).

Referências

Estratégia priorizada descrita nos comentários de progresso da issue #1251.

---

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 — as novas dependências foram verificadas no SBOM/Trivy sem vulnerabilidades críticas/altas em aberto?

  • Verificado e aprovado
  • Pendente / vulnerabilidade aceita com justificativa:

  Este repositório não usa Trivy/SBOM (é biblioteca, não serviço containerizado, conforme SECURITY_ADHERENCE.md seção 3). O gate real de dependências é o Snyk, que roda automaticamente neste PR. Este PR não muda nenhuma versão de dependência de fato instalada (só declara pisos em setup.py/tox.ini que já foram validados e verificados nas fases 1-7).

• Não

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

• Sim
• Não aplicável a este PR (justifique): SonarQube e Trivy não estão configurados neste repositório (SECURITY_ADHERENCE.md seção 3). Os gates automáticos reais (Snyk e GitGuardian) rodam neste PR.

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

• Sim
• Não

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

• Sim
• Não

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

• Não, nenhum segredo foi commitado
• Sim