feat(ambiance): éclairage différencié par équipe

[CCoupel]

Contexte

Issue ajoutée au cœur du milestone v10.0.0 par l'ajustement de périmètre du 2026-09-02 :
c'est la capacité qui justifie le milestone. Sans elle, v10.0.0 livre un vocabulaire
d'événements, un pilote, un écran de configuration et une démonstration bout-en-bout — mais rien de
visible qui relie l'éclairage aux équipes.

Extraite de #211 (milestone v10.1), dont elle reprend le sous-ensemble minimal : une ampoule et
une couleur par équipe. Ce qui reste dans #211 est ce qui est réellement avancé — effets répartis
sur plusieurs ampoules et rôles fins.

Re-planifiée le 2026-09-03. La justification d'origine invoquait l'absence de primitive de
groupe en BLE. Le BLE est abandonné et le pont Hue, lui, sait piloter un groupe — la question a
donc été rouverte et tranchée explicitement.

Pourquoi la promotion reste peu coûteuse — la question du groupe, tranchée

Le contrat contracts/hue-bridge.md §2 tranche : le pilote adresse des ampoules individuelles,
et BuzzMaster détient le mapping équipe → ampoules dans sa propre configuration.

Et c'est précisément cette issue qui emporte la décision : un groupe Hue impose un état
unique à tous ses membres. Or colorer par équipe demande des couleurs différentes en même
temps. Il faudrait un groupe par équipe, souvent d'une seule ampoule — de la comptabilité pour un
gain nul. Le groupe ne servirait que le cas « toute la salle d'une seule couleur », qui n'est pas
le cas différenciant du milestone.

S'y ajoutent : un budget de débit 10× plus favorable aux ampoules (~10 commandes/s sur /lights
contre ~1/s sur /groups), et aucune dépendance à des zones créées à la main dans l'application
Hue, qui peuvent être renommées ou supprimées.

Le pilote #206 écrivant déjà ampoule par ampoule, cette issue n'ajoute que la couche de
correspondance : quelle ampoule représente quoi.

Portée

• Activation du role: "team" et du champ team de la section lighting — schéma déjà figé
  par feat(ambiance): configuration serveur et écran d'administration Éclairage #207, rien à migrer.
• Résolution « quelle équipe concerne cet événement » pour chaque genre du vocabulaire de
  contracts/lighting.md §2. Event.Teams est déjà rempli par feat(ambiance): événements d'ambiance normalisés et pilote d'éclairage abstrait #205 (livré) et par l'amendement
  §6.3 du contrat — cette issue le résout en zones, elle ne le recalcule pas.
• Correspondance zone → ampoules (contracts/hue-bridge.md §5.2) : la zone general couvre
  les ampoules de rôle general plus toute ampoule d'équipe dont l'équipe n'est pas nommée
  dans l'état courant.
• Réemploi strict de la machinerie couleur existante : teamColorPalette
  (cmd/server/main.go:3687), teamColorToRGB (3838), nearestPaletteColorByHue (3797).
  Jamais une seconde palette — la salle et les buzzers doivent montrer la même couleur pour
  la même équipe. Deux rouges différents seraient pires que pas de couleur du tout.
  C'est ce que garantit déjà le format de lighting.ZoneState, identique à
  protocol.LEDSetPayload (RGB [3]int 0-255).
• Règles de dégradation, écrites explicitement dans le contrat. Ce sont elles qui font la
  différence entre une fonctionnalité utilisable et une curiosité de démonstration :
  • moins d'ampoules que d'équipes — le cas le plus fréquent en pratique ;
  • équipe sans ampoule affectée ;
  • aucune ampoule affectée du tout → retour au comportement « toute la salle en general » ;
  • ampoule affectée mais injoignable (éteinte au mur) → ne doit pas empêcher les autres.
• Colonne d'affectation dans la section « Éclairage d'ambiance » de ConfigPage.jsx — aperçu
  en §06 de docs/mockups/lighting-hue-config-207.html.

Hors portée

Effets répartis sur plusieurs ampoules, rôles fins par ampoule, éditeur de scènes — v10.1
(#210, #211).

Critère de fait

• Une équipe buzze : son ampoule prend sa couleur, et c'est la même que celle affichée
  par ses buzzers. Vérifié par comparaison des valeurs RGB, pas à l'œil.
• Les quatre cas de dégradation sont testés séparément et produisent chacun le comportement écrit
  au contrat.
• Aucune ampoule affectée → comportement strictement identique à celui livré par feat(ambiance): pilote Hue Bridge (API REST locale) #206 : la
  pièce en bloc. Cette issue s'ajoute, elle ne remplace pas.
• Le nombre d'écritures par événement reste borné et mesuré (« n'écrire que ce qui change »,
  hue-bridge.md §5.3) : colorer par équipe ne doit pas multiplier le trafic vers le pont.
• L'étalement entre ampoules reste dans l'enveloppe chiffrée par feat(ambiance): pilote Hue Bridge (API REST locale) #206 (§8 du contrat).

Dépendances

#205 (livré), #206 (pilote), #207 (section de configuration et écran). Précède #208, qui la vérifie
bout-en-bout.