fix: evita duplicacao e mau posicionamento de tabela em subsecao aninhada

[Rossi-Luciano]

O que esse PR faz?

Corrige extract_body_data (packtools/sps/formats/pdf/pipeline/xml.py) para que uma <table-wrap> dentro de uma subseção aninhada seja coletada uma única vez, na seção certa, em vez de ser duplicada (uma cópia despejada em bloco na seção-pai, antes de qualquer parágrafo, e outra na posição natural dentro da subseção).

Onde a revisão poderia começar?

packtools/sps/formats/pdf/pipeline/xml.py, função extract_body_data, no loop for table_wrap in document_section.findall('.//table-wrap'). A correção checa se a <sec> ancestral mais próxima da tabela (table_wrap.xpath('ancestor::sec[1]')) é a própria seção em processamento; se não for, a tabela é pulada ali e coletada quando o loop chegar na seção certa. Não depende de @id (funciona mesmo sem ele, diferente do dedup por chave que existe pra figura).

Como este poderia ser testado manualmente?

python -m packtools.sps.formats.pdf_generator \
    -i tests/fixtures/pdf/a1.xml \
    -l tests/fixtures/pdf/layout.docx \
    -o /tmp/a1.pdf --libreoffice-binary libreoffice

Testes automatizados novos em tests/sps/formats/pdf/pipeline/test_xml.py::TestExtractBodyDataTableDedup cobrem: tabela em subseção não duplica, tabela fica na seção certa (não sobe pra seção-pai), funciona sem @id, e tabela direta na seção-pai não é pulada por engano.

Algum cenário de contexto que queira dar?

Achado durante uma auditoria do gerador de PDF contra um corpus de 26 artigos reais publicados. Renderizando a5.xml (5 tabelas, várias em subseção) via LibreOffice, cada tabela aparecia 2-3 vezes no PDF gerado, a primeira leva delas despejada em bloco logo após o título de "2. MATERIALS AND METHODS", antes de qualquer parágrafo de corpo. A causa raiz é que findall('.//sec') visita cada seção aninhada como entrada própria, e cada uma busca .//table-wrap em todos os descendentes, então uma tabela numa subseção é coletada tanto pela seção-pai quanto pela subseção. O loop de figuras já tinha proteção equivalente (seen_fig_keys), o de tabelas não tinha.

Screenshots

## Quais são os tickets relevantes?

Closes #1313.

Referências

N/A

---

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
• Não

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

• Sim
• Não aplicável a este PR (correção de extração de dados internos, sem novas dependências ou superfícies expostas)

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

[pitangainnovare]

Funciona como esperado.