feat(drivers): pool géo candidats trajet préparé et charge prépa/prod pour chaînage

Avant

• Les suggestions pouvaient s’appuyer sur une liste très large de chauffeurs « présents sur la période », sans priorité géographique par rapport au trajet.
• Les obligations déjà portées sur d’autres trajets préparés étaient surtout vues au fil de l’eau (requêtes par chauffeur / jour), ce qui compliquait une vision globale et cohérente des créneaux.
• Le fonctionnement métier après la préparation (créneaux réels côté production) n’était pas pris en compte dans l’outil de suggestion : distinction disponible / enchaînable restait alignée quasi uniquement sur la prépa, donc peu réaliste dès que le chauffeur a déjà du PROD autour du même créneau.
• Sans configuration dédiée, aucune option claire pour brancher progressivement une source PROD de charge transport sur l’environnement cible.

Après

• La suggestion priorise les chauffeurs proches géographiquement du trajet (avec repli si la zone ne retourne personne).
• Les charges prépa pertinentes sont agrégées en amont pour l’ensemble des candidats et des jours considérés, pour des contrôles de conflit et de chaînage plus fiables et de meilleures perfs qu’une lecture au cas par cas.
• Une option de configuration permet, quand elle est activée (preparation.driver-workload), d’enrichir l’analyse avec des occupations PROD, pour mieux refléter disponible vs enchaînable lorsque le chaînage est autorisé et que les données sont exposées.
• Les paramètres de cette intégration PROD sont déclarés proprement au démarrage de l’application pour un déploiement par environnement (sans code local spécifique).