Vœu de compagnon : traité comme réciproque par le solveur

Le vœu reste à sens unique en base (A choisit B sur sa fiche, B n'a rien à
faire) mais si A souhaite B, B doit désormais profiter aussi de la présence
de A — dans les deux sens : affecter A d'abord fait remonter B comme
candidat, et affecter B d'abord fait remonter A, même si B n'a rien demandé.

- Solveur (`loader.py`) : le vœu (A → B) alimente maintenant l'ensemble
  effectif des deux bénévoles (A et B), pas seulement celui du demandeur.
  Aucun changement dans `engine.py` : il ne fait que lire un ensemble déjà
  symétrisé.
- Mock (`buildEffectiveCompanions`) et classement par défaut
  (`buildEffectiveCompanionIds` dans `lib/planning.ts`, utilisé par
  `AssignmentPanel.tsx`) : même symétrisation, pour rester cohérents avec le
  vrai solveur.
- La fiche bénévole (vœux affichés/édités) n'est pas touchée : c'est le seul
  endroit qui reste à sens unique, par construction (la réciprocité n'est
  qu'une lecture, jamais une donnée enregistrée — sinon éditer sa propre
  liste risquerait d'effacer le vœu de quelqu'un d'autre).
- Nouveau test d'intégration : le bénévole qui n'a rien demandé profite quand
  même de la présence de celui qui l'a choisi.
- CLAUDE.md à jour.

Vérifié : 193 tests backend pertinents (dont le nouveau), ruff, alembic
check ; typecheck/lint/build/smoke frontend.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017uUsRg7XzopkCPWimwg9ZM

backend/app/solver/engine.py

@@ -49,7 +49,8 @@ _ARTIST_CONFLICT_PENALTY = 80
 # n'importe quel poste) : limite les enchaînements de shifts plutôt que de
 # faire tourner un poste en particulier.
 _CHAIN_PENALTY = 40
-# Par compagnon souhaité déjà affecté au créneau (0 à N vœux par bénévole).
+# Par compagnon souhaité déjà affecté au créneau (0 à N vœux par bénévole,
+# rendus réciproques par le loader — voir `SolverVolunteer.wished_companion_ids`).
 _COMPANION_BONUS_PER_MATCH = 25
 
 

backend/app/solver/loader.py

@@ -102,6 +102,9 @@ def build_solver_input(*, session: Session, edition: Edition) -> SolverInput:
     ):
         wishes[w.volunteer_id].add(str(w.position_id))
 
+    # Traité comme réciproque pour le solveur : si A souhaite B, B profite
+    # aussi de la présence de A, même s'il ne l'a pas demandé (voir CLAUDE.md
+    # section 4).
     companion_wishes: dict = defaultdict(set)
     for w in session.exec(
         select(VolunteerCompanionWish).join(
@@ -109,6 +112,7 @@ def build_solver_input(*, session: Session, edition: Edition) -> SolverInput:
         ).where(Volunteer.edition_id == edition.id)
     ):
         companion_wishes[w.volunteer_id].add(str(w.companion_id))
+        companion_wishes[w.companion_id].add(str(w.volunteer_id))
 
     artists_by_id = {
         a.id: a

backend/app/solver/models.py

@@ -41,7 +41,9 @@ class SolverVolunteer:
     id: str
     availability: tuple[AvailabilityWindow, ...] = ()
     wished_position_ids: frozenset[str] = frozenset()
-    # Bénévoles (0 à N) avec qui il voudrait être affecté — à sens unique.
+    # Bénévoles (0 à N) avec qui il voudrait être affecté. Le vœu est saisi à
+    # sens unique (`VolunteerCompanionWish`) mais rendu réciproque ici par le
+    # loader : si A souhaite B, l'ensemble de B contient aussi A.
     wished_companion_ids: frozenset[str] = frozenset()
     # Passages des artistes que le bénévole veut voir (heure de passage),
     # sous forme de fenêtres datées : un créneau qui chevauche l'une d'elles