Grille : les candidats sont classés par score de chance, pas par charge

Dans le panneau d'affectation, la liste des candidats d'un créneau
n'était triée que par disponibilité puis par nombre d'heures déjà
assignées — les vœux n'y jouaient aucun rôle tant qu'on ne cliquait pas
sur « Suggestions (solveur) ».

Nouveau `candidateChanceScore` (`lib/planning.ts`), portage local et
synchrone du scoring du solveur : vœu de poste (bonus), disponibilité
déclarée y compris conflit avec un artiste souhaité (malus), charge déjà
assignée (malus). C'est ce score qui classe désormais la liste par
défaut, dès l'ouverture du détail d'un poste — sans requête réseau ni
clic sur le solveur. Si celui-ci a effectivement tourné, ses candidats
retenus (vraie optimisation jointe) restent prioritaires en tête.

Chaque candidat affiche maintenant, en plus de sa disponibilité, des
badges « Vœu de poste » et « Manquerait un artiste souhaité » quand
applicable — pour que le classement reste lisible.

typecheck / lint / build / smoke au vert.

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

CLAUDE.md

@@ -279,6 +279,16 @@ affectation n'est jamais persistée par cet endpoint.
     même calcul — la validation finale à la confirmation reste seule juge de
     ce cas limite.
 
+**Classement par défaut, sans lancer le solveur** — `frontend/src/lib/planning.ts`
+(`candidateChanceScore`) porte une version simplifiée du même scoring (vœu de
+poste, disponibilité y compris conflit d'artiste, charge déjà affectée ; pas
+de cumul 8 h / repos, déjà couverts par les badges de validation). C'est ce
+qui classe la colonne des candidats dans le panneau d'affectation dès
+l'ouverture du détail d'un poste, sans requête réseau. Si le solveur a
+effectivement tourné (`POST .../solver/suggestions`), ses bénévoles retenus
+passent malgré tout en tête (ce sont eux le résultat d'une vraie optimisation
+jointe, pas juste un score local).
+
 ---
 
 ## 5. Périmètre