feat: recherche intégration avec simulation ORS et occupations chauffeur complètes

Avant

• La recherche de circuits pour l’intégration / l’optimisation se basait surtout sur la distance et la durée déjà enregistrées sur le trajet, ce qui ne reflétait pas correctement le parcours réel si l’on ajoutait des arrêts ou des passagers (waypoints issus de la préparation). Les plafonds km/minutes pouvaient donc être peu fiables par rapport au scénario de fusion réel.
• La vue occupations chauffeur (planning par jour) ne reflétait pas toujours les services où le chauffeur est affecté au trajet mais où le TripDay n’a pas été recopié avec son UUID chauffeur : la préparation ou le chaînage pouvaient voir des trous ou des listes incomplètes alors que l’affectation existait bien en base.

Après

• Lorsque la préparation envoie des waypoints candidats valides avec des plafonds distance / durée, le service simule un itinéraire de type véhicule (ORS) qui enchaîne le trajet existant et ces points, et applique les plafonds sur cette métrique fusionnée ; sinon il conserve le comportement attendu sur les valeurs stockées du trajet, avec des règles de tolérance cohérentes pour l’historique.
• Les occupations par chauffeur sur une plage de dates agrègent les TripDay trouvés par chauffeur direct et ceux rattachés aux affectations (y compris les affectations inactives si demandé), ce qui aligne l’API sur la réalité opérationnelle : un chauffeur assigné à un trajet sur un jour donné apparaît dans le planning même si la dénormalisation tripDriverUuid n’a pas été faite sur le TripDay.