"""Chargement des types de jobs métier — le pendant exact de `app/db/models.py`.

Le worker est **neutre** : il ne connaît aucun type métier, seulement le registre (socle
§2.2). Un type ne s'y déclare qu'à l'import du module qui le possède. Un process worker qui
n'importe pas ce module démarre donc avec un registre vide et met `failed` — « type de job
inconnu » — **tous** les jobs de la file, sans que rien n'ait l'air cassé au démarrage.

C'est le piège que le rapport T0 signalait explicitement (concern n°1) : les imports sont ici
et nulle part ailleurs, dans un module dédié qu'appellent les deux points d'entrée du
processus — `app.jobs.worker._run` (le worker) et `app.main.create_app` (l'api, dont
`service.enqueue` refuse un type absent du registre). `test_jobs_loader.py` lance un vrai
worker **à froid** et lit les types qu'il annonce : l'oubli fait échouer la suite.

Ajouter un type = ajouter son import ici, jamais ailleurs.
"""

from app.jobs import registry


def load_job_types() -> list[str]:
    """Importe les modules qui enregistrent des types de jobs. Idempotent (cache d'import).

    Les **tâches périodiques** (T8 : le sweep des synchros dues) se déclarent au même endroit
    et par le même mécanisme — un worker qui ne les importerait pas tournerait sans jamais
    honorer un rendez-vous, en silence. `app.integrations.service` importe lui-même
    `app.integrations.pipeline`, donc la ligne ci-dessous couvre le type `import_api` *et* le
    planificateur.
    """
    from app.integrations import service as _integrations  # noqa: F401
    from app.keywords import pipeline as _pipeline  # noqa: F401  (l'import *est* l'effet)

    return registry.registered_names()