[FIX] base_bg: do not let one job break the whole reaper

[nicomacr]

Problema

Un job cuyos registros objetivo ya no existen revienta al ser dado por vencido: fail() browsea esos ids para linkearlos en la notificación y, como browsear un id borrado devuelve un recordset truthy, leer su display_name levanta MissingError. La excepción aborta el loop entero de _cron_check_running_jobs: la transacción se rollbackea, el job envenenado queda en running y ningún otro job colgado se procesa, en esa corrida ni en las siguientes.

El mismo fail() corre desde run() → _handle_job_error → _give_up, así que un job con su target borrado también aborta el cron del runner.

Cambio

• Causa raíz: fail() chequea existencia real (_get_records().exists()) antes de linkear los registros en la notificación. Aplica a jobs de cualquier modelo.
• Hardening del reaper: cada job se maneja en su propio savepoint. Error transitorio de PG (_is_transient_error) → warning y se deja para la próxima corrida; cualquier otra cosa (típicamente un override del modelo que revienta) → el job se marca failed con las implementaciones base, sin notificar, y se cancela el resto del batch. Ese camino de recuperación corre en su propio savepoint, así que si también revienta el reaper sigue con los demás jobs vencidos.

Tests

base_bg/tests/test_bg_job.py:

• test_fail_notifies_when_records_were_deleted: fail() sobre un job cuyos registros se borraron → queda failed sin levantar MissingError.
• test_cron_check_running_jobs_skips_poisoned_job: un override de fail() que revienta + un job sano → el envenenado queda failed con su batch cancelado y el sano se vence igual.
• test_cron_check_running_jobs_defers_transient_error: SerializationFailure → el job queda running para la próxima corrida.

Tarea: https://www.adhoc.inc/odoo/project.task/72579

[roboadhoc]

[JoelZilli]

Re-revisado después del amend. LGTM, sin bloqueos — dejo esto como comentario y no como Approve formal por ahora, pero de contenido está aprobado de mi lado.

Verificado

• fail() con _get_records().exists(): la raíz queda cerrada y el camino que me preocupaba converge — run() → except → _handle_job_error → _give_up → fail ya no levanta, así que _cron_run_enqueued_jobs no aborta más. Aplica a jobs de cualquier modelo, como dice el body.
• Fallback en su propio savepoint + try/except: tenés razón en la corrección, el savepoint solo no alcanzaba porque la excepción se propagaba igual y mataba el loop.
• Afuera el invalidate_all(flush=False), con el comentario que explica por qué no hace falta.
• Mi observación sobre mapped() estaba mal y tu corrección es correcta: en Odoo 19, mapped(func) sobre un recordset vacío llama func(self) una vez con el recordset entero (orm/models.py:6174-6183), así que el r and sí cubría el caso vacío — lo que no cubría era el id borrado, que es el bug. La conclusión no cambia y if records: + comprehension explícita es mejor que sacar el lambda a secas.
• El cambio del test envenenado es acertado: con el fix de fail(), borrar el partner ya no envenena nada, así que el test viejo hubiera pasado incluso sin el savepoint. Chequeé que patch.object(type(self.BgJob), "fail", ...) no toca el BgJob.fail del fallback (clase de módulo, distinta de la del registry) y que base_fail se captura antes del patch: el test ejercita de verdad el camino de recuperación.

Nits

Tres comentarios inline, ninguno bloquea. Nada más de mi lado.

_{No corrí los tests localmente (habría que cambiar de rama en mi working tree); me apoyo en el CI. Verifiqué mapped() y la semántica de _FlushingSavepoint leyendo el core 19.}

[nicomacr]

@roboadhoc r+ nobump