Unificar as mudanças no `pid_provider` do `scms-upload` e do `core`: auditoria de registro, aprimoramento de matching/persistência e otimizações de query

[robertatakenaka]

Descrição:

O app pid_provider é compartilhado entre core e upload, e de tempos em tempos é preciso sincronizar os avanços feitos em paralelo nos dois lados. Nesta rodada, o lado upload avançou em pontos que valem a pena trazer para o core:

1. Auditoria de falhas no fluxo de registro

Hoje, quando PidProviderXML.register() falha antes de existir um registro (unmatched, conflito, bad_request, erro inesperado), a única rastreabilidade é via UnexpectedEvent, sem padronização de status nem filtro fácil no admin. Precisamos de um modelo de auditoria que grave sempre o resultado do fluxo (created/updated/skipped/forbidden/conflict/unmatched/bad_request/error), inclusive quando não há PidProviderXML associado.

2. Matching de XML por soma de pontos fixos é frágil

O matching atual (best_matches/match/title_similarity) soma pontos fixos por campo batido (+100 aqui, +10 ali) sem um critério comparável entre as diferentes estratégias de busca (por ids / por journal+issue+artigo / por journal+artigo). Isso dificulta calibrar o corte de aceitação e entender por que um documento foi ou não considerado "o mesmo".

3. Bugs encontrados na revisão

• fix_duplicated_pkg_name acessa other_pid.current_version, campo que não existe em OtherPid (o campo correto é version) — isso lançaria AttributeError em produção sempre que houver deduplicação com other_pid do tipo pid_v3.
• mark_items_as_invalid calcula invalid = bool(item.xml_with_pre) mas nunca persiste o resultado — o método hoje não tem efeito nenhum no banco.

4. Falta de rastreio estruturado de falhas por URL (XMLURL)

XMLURL guarda só uma string de exceptions truncada manualmente (_truncate_traceback), sem status padronizado (choices) nem campo estruturado pra guardar a resposta completa do registro. Isso dificulta investigar falhas de fetch/registro em lote.

5. Repetição de select_related("current_version")

Vários classmethods de PidProviderXML repetem manualmente select_related("current_version") — candidato natural a manager customizado.

Critério de aceite:

• Novo modelo PidProviderXMLRegistration grava o resultado de todo register(), com FK nullable para PidProviderXML.
• Matching reescrito com score percentual comparável (compare()/get_best_match()), documentando o formato de retorno.
• Bug do other_pid.version corrigido.
• mark_items_as_invalid passa a persistir via bulk_update.
• XMLURL ganha status com choices, campo detail (JSON) e método record() centralizando a gravação.
• PidProviderXMLManager aplica select_related("current_version") por padrão.
• Novos ViewSets de admin para XMLURL e PidProviderXMLRegistration.
• XMLEvent (já em produção no core) não é alterado nem unificado com PidProviderXMLRegistration — são domínios de falha diferentes (registro de PID vs. consumo do XML para gerar Article) e a diferença de nullability/cascade é proposital.