Corrige geração de executável do SPSValidator para Windows

[pitangainnovare]

O que esse PR faz?

Corrige o empacotamento do SPSValidator para Windows para gerar um único
arquivo executável.

O script utilizava o modo padrão onedir do PyInstaller, mas somente o arquivo
.exe era distribuído. Por isso, ao iniciar, o programa não encontrava
dependências externas como _internal/python312.dll.

O comando de build passa a usar --onefile e --clean. A documentação também
foi atualizada para descrever o formato do artefato, a necessidade de gerar o
build em Windows e a verificação recomendada antes da publicação.

Onde a revisão poderia começar?

A revisão pode começar em
spsvalidator/packaging/build_windows.ps1, onde foi alterado o modo de geração
do executável.

Em seguida, as instruções correspondentes podem ser revisadas em:

• spsvalidator/packaging/README.md
• spsvalidator/README.md

Como este poderia ser testado manualmente?

Em uma máquina Windows com Python instalado:

1. Acessar o diretório spsvalidator, onde está o pyproject.toml.

2. Remover os diretórios build e dist de builds anteriores.

3. Executar:

   powershell -ExecutionPolicy Bypass -File packaging/build_windows.ps1

4. Confirmar que foi criado somente o artefato dist/spsvalidator.exe.

5. Copiar spsvalidator.exe para uma pasta vazia, sem _internal ou outros
   arquivos auxiliares.

6. Executar o arquivo e confirmar que a interface abre sem o erro relacionado
   a python312.dll.

7. Validar um pacote SPS em formato .zip.

8. Conferir o relatório, exportar o CSV e encerrar o aplicativo.

O executável gerado durante a análise também foi inspecionado estaticamente. O
arquivo contém o interpretador Python 3.12, os módulos da aplicação, templates,
traduções e as principais dependências dentro do bundle do PyInstaller.

Algum cenário de contexto que queira dar?

Na versão 0.3.0, o executável foi distribuído sem o diretório _internal
produzido pelo modo onedir. Ao tentar iniciá-lo no Windows, o bootloader do
PyInstaller procurava python312.dll nesse diretório e encerrava o programa
antes da abertura da interface. Como o requisito de distribuição é um executável único, este PR adota o modo onefile em vez de exigir a distribuição de toda a pasta gerada pelo modo
onedir.

Screenshots

N/A

Quais são os tickets relevantes?

Closes #43.

Referências

N/A

---

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

Seção obrigatória. Marque as opções aplicáveis e justifique quando necessário. Referência: NSI.04 - Norma de Desenvolvimento Seguro.

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

• Sim — descreva os controles de proteção aplicados (criptografia, mascaramento, anonimização, etc.):
• Não

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

• Sim — descreva o que mudou e por quê:
• 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:
• Não

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

• Sim — link do job:
• Não aplicável a este PR (justifique): a alteração está restrita às opções de empacotamento e à documentação; não há mudança no código da aplicação nem nas dependências.

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

• Sim — confirme que há sanitização/parametrização (prepared statements, escaping, etc.):
• Não

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

• Sim — HTTPS obrigatório está garantido e o acesso segue o princípio de menor privilégio?
• Não

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

• Não, nenhum segredo foi commitado
• Sim (bloquear merge e corrigir antes de prosseguir)