feat(pubmed): adicionar Suffix e CollectiveName em AuthorList

[Rossi-Luciano]

O que esse PR faz?

Implementa <Suffix> e <CollectiveName> em <AuthorList> no conversor SPS → PubMed XML (packtools/sps/formats/pubmed.py), fechando 2 dos # TODO marcados no código original. Os dados já estavam disponíveis no model article_contribs.Contrib (contrib_name["suffix"] e collab), só faltava conectar.

A DTD do PubMed exige que <Author> tenha nome pessoal OU CollectiveName, nunca os dois juntos:

<!ELEMENT Author (((FirstName, MiddleName?, LastName, Suffix?, Initials?) | CollectiveName), %affiliation;, Identifier*)>

xml_pubmed_author_list agora respeita essa exclusividade: contribs que só têm <collab> (sem <name>) — o padrão SPS 1.10 para autoria em grupo — geram <Author><CollectiveName>...</CollectiveName></Author>; os demais continuam gerando FirstName/LastName/Suffix como antes.

Também corrige um bug em get_affiliations: contribs sem afiliação vinculada (comum justamente no caso de CollectiveName, cujo único xref costuma apontar para author-notes, não para aff) não tinham a chave "affs" no dicionário, e for item in author_reg.get("affs") lançava TypeError: 'NoneType' object is not iterable. Sem esse fix, qualquer artigo com autoria em grupo quebraria o pipeline inteiro ao tentar gerar CollectiveName.

Onde a revisão poderia começar?

packtools/sps/formats/pubmed.py: add_suffix, add_collective_name (funções novas), get_affiliations (fix de uma linha), e xml_pubmed_author_list (lógica de exclusividade FirstName/LastName vs. CollectiveName).

Como este poderia ser testado manualmente?

1. Rodar a suíte: source .venv/bin/activate && python -m pytest tests/sps/formats/test_pubmed.py -v (48 passed: 46 originais + 2 novos).
2. Reproduzir o bug do get_affiliations antes do fix (reverter só essa linha) e rodar:

   from lxml import etree as ET
   from packtools.sps.formats import pubmed
   
   xml_tree = ET.fromstring(
       '<article xmlns:mml="http://www.w3.org/1998/Math/MathML" '
       'xmlns:xlink="http://www.w3.org/1999/xlink" article-type="research-article" '
       'dtd-version="1.1" specific-use="sps-1.9" xml:lang="en">'
       '<front><article-meta>'
       '<contrib-group>'
       '<contrib contrib-type="author" id="collab">'
       '<collab>The SciELO Group</collab>'
       '<xref ref-type="author-notes" rid="fn1">1</xref>'
       '</contrib>'
       '</contrib-group>'
       '</article-meta></front></article>'
   )
   xml_pubmed = ET.fromstring('<Article/>')
   pubmed.xml_pubmed_author_list(xml_pubmed, xml_tree)
   print(ET.tostring(xml_pubmed, pretty_print=True).decode())

   Sem o fix: TypeError: 'NoneType' object is not iterable. Com o fix: <Author><CollectiveName>The SciELO Group</CollectiveName></Author>, sem FirstName/LastName vazios.
3. Rodar contra um artigo real (tests/samples/0034-7094-rba-69-03-0227.xml, sem autoria em grupo) para confirmar que o comportamento de autores individuais não mudou.

Algum cenário de contexto que queira dar?

Parte da quebra da #1226 em sub-issues. O padrão SPS 1.10 para autoria em grupo (documentado no guia interno da SciELO) é:

<contrib-group>
   <contrib contrib-type="author" id="collab">
     <collab>The SciELO Group</collab>
   </contrib>
</contrib-group>
<contrib-group content-type="collab-list">
    <contrib contrib-type="author" rid="collab">
      <name>...</name>
    </contrib>
    ...
</contrib-group>

Este PR cobre apenas o <collab> do primeiro contrib-group (o "nome do grupo"). Os membros individuais do content-type="collab-list" continuam sendo listados como Author comuns em AuthorList (comportamento herdado, sem mudança) — mover esses membros para GroupList/IndividualName é escopo da #1237, que também depende deste PR (mesma função xml_pubmed_author_list).

Quais são tickets relevantes?

Closes #1236. Relacionado a #1226 (issue-mãe), #1237 (depende deste PR).

Referências

• DTD oficial do PubMed: https://dtd.nlm.nih.gov/ncbi/pubmed/in/PubMed.dtd (elemento Author)
• Guia SciELO SPS 1.10, seção <contrib>: <name> e <collab> — exemplos de autoria em grupo

[Rossi-Luciano]

Validado localmente contra a DTD oficial do PubMed (https://dtd.nlm.nih.gov/ncbi/pubmed/in/PubMed.dtd, via lxml.etree.DTD), combinando esta branch com o #1243 (#1234, necessário porque a DTD exige a raiz ArticleSet):

• Suíte de testes: passou sem regressões.
• Artigo real (tests/samples/0034-7094-rba-69-03-0227.xml): VALID: True.
• Também testado combinando todos os PRs abertos (feat(pubmed): envolver saída em ArticleSet/DOCTYPE e corrigir ordem dos elementos #1243–feat(pubmed): adicionar Object[@Type=grant] (financiamento) em ObjectList #1248) num artigo sintético que exercita as features de todos eles ao mesmo tempo (grupo de autoria, financiamento, copyright, coi-statement): VALID: True.

(O validador linkado na issue-mãe #1226 não serve para este formato — ver comentário em #1226.)

[Rossi-Luciano]

Adicionado mais um commit a este PR. Achado ao validar a #1241 (CLI em lote) contra a DTD real usando `tests/samples/example.xml`: a DTD do PubMed exige `FirstName` e `LastName` sempre juntos em `Author` (nenhum dos dois é opcional isoladamente), mas há um contrib nesse artigo real com `` e sem ``, gerando `...` sem `LastName` — inválido segundo a DTD (confirmei empiricamente: `Author` só com `FirstName` ou só com `LastName` sempre falha).

`add_first_name`/`add_last_name` agora caem para o outro campo quando o esperado está ausente, duplicando o único nome disponível em ambos. Teste de regressão adicionado.

Suíte: 49/49 passando.