Gestion des référents depuis la fiche bénévole

Un poste avait bien un `lead_account_id`, lu par l'écran référent
(`/mobile-referent`) et par les droits d'écriture (`ensure_can_write_position`),
mais rien ne permettait de le renseigner : aucun écran ne l'exposait, et
l'API ne validait même pas que la valeur envoyée désignait un compte référent
existant de la bonne édition.

Backend :
- `PATCH /editions/{id}/accounts/{account_id}` (nouveau) : change le `role`
  d'un compte, seulement entre LEAD et VOLUNTEER (lien magique dans les deux
  cas) — 422 `account.role_change_not_allowed` dès que COORDINATOR est
  impliqué (mot de passe en jeu, jamais touché ici). C'est ce qui permet de
  faire passer le compte d'un bénévole en référent.
- `POST`/`PATCH /positions` : `lead_account_id` vérifié — doit désigner un
  compte `Role.LEAD` de la même édition, sinon 422
  `position.lead_must_be_referent_account` (silencieusement accepté
  jusqu'ici, y compris un compte d'une autre édition ou du mauvais rôle).

Frontend (`ConfigVolunteers.tsx`) : nouvelle section « Référent des postes »
sur la fiche du bénévole, juste après l'accès de connexion — mêmes badges à
cocher que les vœux de poste/artiste. Cocher un poste crée ou met à niveau
(LEAD) l'accès de connexion du bénévole automatiquement ; décocher retire
seulement le poste, sans jamais rétrograder l'accès. Un bénévole dont le
compte est déjà COORDINATOR ne peut pas être désigné référent (il a déjà
accès à tout). Miroir complet côté mock (`accounts.update`,
`checkLeadAccount`) pour que la démonstration se comporte pareil.

Vérifié : 204 tests backend pertinents (14 nouveaux : 6 sur `PATCH accounts`,
8 sur la validation `lead_account_id`), ruff, alembic check ; typecheck/
lint/build/smoke frontend ; parcours complet testé en direct sur le jeu de
démo (création de compte, promotion LEAD, rejet COORDINATOR, affectation
référent) avant nettoyage des données de test.

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

CLAUDE.md

@@ -93,7 +93,15 @@ les tables sauf les tables d'association.
   unique et éditable indépendamment par chacun). `CHECK (volunteer_id <>
   companion_id)` : un bénévole ne peut pas se souhaiter lui-même.
 - **`Position`** : `name`, `location`, `category` (`PositionCategory`),
-  `lead_account_id` (→ `Account`, `SET NULL` à la suppression du compte).
+  `lead_account_id` (→ `Account`, `SET NULL` à la suppression du compte) —
+  doit désigner un compte `Role.LEAD` de la même édition (`POST`/`PATCH`
+  `/positions` le vérifient, 422 `position.lead_must_be_referent_account`
+  sinon). Se gère depuis la fiche du bénévole (`ConfigVolunteers.tsx` :
+  section « Référent des postes ») plutôt que depuis le poste : cocher un
+  poste y crée ou met à niveau (`PATCH /accounts/{id}` : voir plus bas) son
+  compte en `LEAD` — à sa prochaine connexion il voit l'écran référent
+  (`/mobile-referent`) plutôt que l'écran bénévole. Décocher ne fait que
+  retirer le poste, sans jamais rétrograder le compte automatiquement.
 - **`Shift`** : `position_id`, `day_part_id` (nullable ; le créneau type dont
   il est issu, `SET NULL` si le type est supprimé), `starts_at`, `ends_at`
   (peut finir le lendemain), `min_staff`, `ideal_staff`. À la création d'un
@@ -188,6 +196,13 @@ pour ne jamais révéler si un compte existe). Front : bouton « Donner un accè
 de connexion » sur la fiche du bénévole (`ConfigVolunteers.tsx`), qui appelle
 cet endpoint avec `role=VOLUNTEER`.
 
+`PATCH /editions/{id}/accounts/{account_id}` change uniquement le `role`, et
+seulement entre `LEAD` et `VOLUNTEER` (lien magique dans les deux cas) — 422
+`account.role_change_not_allowed` si `COORDINATOR` est impliqué dans un sens
+ou l'autre (mot de passe en jeu, jamais touché par cette route). C'est ce qui
+met à niveau le compte d'un bénévole en référent quand on le désigne
+référent d'un poste (voir `Position.lead_account_id` plus haut).
+
 ### Emails (`app/email/`)
 
 Envoi par **SMTP** (auto-hébergé). `EMAIL_ENABLED=false` (défaut dev/tests) ⇒
@@ -495,6 +510,7 @@ Aucune dépendance locale requise hors Docker.
 | 15    | Solveur de suggestions OR-Tools CP-SAT (section 4) : `POST /editions/{id}/solver/suggestions`, candidats remontés en tête de liste dans la grille des besoins — aucune affectation automatique | à valider |
 | 16    | Bénévole : l'email n'est plus unique (couple, famille) — identification par (email, nom + prénom) dans l'import et l'API, plus de rejet 409 à la création manuelle | à valider |
 | 17    | Vœu de compagnon (`VolunteerCompanionWish`, 0 à N, à sens unique) : fiche bénévole, pris en compte par le solveur (bonus) et le classement par défaut | à valider |
+| 18    | Gestion des référents depuis la fiche bénévole : `PATCH /accounts` (rôle LEAD ↔ VOLUNTEER), `lead_account_id` vérifié (doit être un compte référent de l'édition) | à valider |
 
 **Reste hors périmètre** (modèle prêt à les accueillir) : SMS, constructeur
 de formulaire, pointage sur site, IA. Frontend : squelette + 6 écrans +