Reduzir dependência de XMLEvent/ArticleEvent no pipeline de artigos, consolidando em UnexpectedEvent

[robertatakenaka]

Descrição

Este trabalho tem como objetivo central reduzir o número de modelos de evento
específicos (ArticleEvent, XMLEvent) usados hoje para registrar progresso
e falhas no pipeline de processamento de artigos, consolidando esse registro
em UnexpectedEvent — modelo já existente e mais genérico — sempre que
possível.

Motivação:

• ArticleEvent/XMLEvent exigem a criação prévia de um objeto de evento
  (article.add_event(...)), o que gera ramificações de código do tipo
  if event: ... else: ... e falha silenciosa quando o evento não chega a
  ser criado (ex.: artigo ainda não existe, ou exceção ocorre antes da
  criação do evento).
• UnexpectedEvent.create(...) não depende de um objeto de evento
  pré-existente, é chamado de forma incondicional, e pode receber contexto
  suficiente (action, item, detail) para diagnóstico, sem exigir um
  modelo dedicado por entidade (ArticleEvent para artigo, XMLEvent para
  XML, etc.).
• Menos modelos de evento significa menos migrations, menos tabelas para
  manter, e uma única fonte de consulta para diagnosticar falhas em todo o
  pipeline (article, proc, pid_provider).

Escopo desta etapa

• article/tasks.py: task_export_article_to_articlemeta,
  task_process_article_pipeline — padronizar chamadas a
  UnexpectedEvent.create(action=..., item=..., detail=...).
• article/sources/xmlsps.py: load_article — remove uso de
  ArticleEvent (add_event/event.finish), substituindo por uma função
  finish(article, errors, messages) que grava direto em article.errors.
• article/models.py: Article.check_availability — remove dependência do
  event (ArticleEvent), chamando UnexpectedEvent.create(...)
  incondicionalmente.

Fora de escopo (próximas etapas)

• Remoção efetiva dos modelos ArticleEvent/XMLEvent do banco (migration
  de remoção), caso este PR confirme que nenhum outro ponto do código ainda
  depende deles.
• Avaliar pid_provider (XMLEvent) para o mesmo tratamento.

Critérios de aceite

• Nenhuma chamada nova a article.add_event(...) foi introduzida nos
  arquivos alterados.
• Todas as chamadas a UnexpectedEvent.create(...) no escopo usam
  action e item de forma consistente.
• load_article persiste erros e mensagens de progresso em
  article.errors, sem depender de ArticleEvent.
• Nenhuma exceção é perdida (silenciada) nos fluxos de erro.
• Imports não utilizados removidos (logging, sys, etree,
  Location, PPXML_STATUS_*, PidProviderXML, UnexpectedEvent
  onde não mais usado em xmlsps.py).
• Levantamento (comentário na issue) de quantos usos de
  ArticleEvent/XMLEvent ainda restam no restante do código, para
  planejar a remoção dos modelos.