GameTheory-02c : domination faible présentée comme stricte + r=1 multi-équilibres non traité (défaut révélé par le twin 02d) #15461

Défaut révélé par la variante de maturation GT-02d (EPIC #12208, temps 2)

La re-dérivation C# du matériau 02c (PR #15437, review ai-01 au head 27bc683) a révélé que 02c porte un défaut conceptuel central que sa formulation présentait comme acquis. Le twin a recopié le défaut avant que la review ne le nomme — les deux notebooks portent donc les mêmes formulations à corriger ; cette issue track la correction du twin Python d'origine.

Les deux défauts

1. Domination faible présentée comme stricte. Le prédicat utilisé pour l'élimination itérée est « paiement >= pour tout adversaire et > pour au moins un » : c'est la définition de la domination faible. Dans le Traveler's Dilemma, pour toute stratégie adverse y < k-1, les stratégies k-1 et k donnent toutes deux y - r, donc k-1 n'est jamais strictement meilleure partout — l'élimination itérée au sens strict ne s'applique pas telle quelle. La section et le code doivent être reformulés en « élimination itérée de stratégies faiblement dominées ».

2. Le cas r = 1 invalide « unique équilibre (2,2) dès que r >= 1 ». Pour y > 2, sous-coter à y-1 et rester à y donnent tous deux y : la correspondance de meilleures réponses contient {y-1, y}, et chaque profil diagonal (y, y) est un équilibre de Nash à r = 1. Le tie-breaking strict (> garde le plus petit argmax) du code est une convention algorithmique, pas une unicité mathématique. Il faut séparer explicitement : r > 1 (sous-cotage strictement profitable, équilibre pur unique au plancher) · r = 1 (égalités de BR, multiples équilibres, élimination faible dépendant d'une convention d'ordre) · r < 1.

Acceptance

• Section élimination : « strictement dominées » → « faiblement dominées » partout (prose + code + claims)
• r = 1 traité comme cas à part (BR multi-valuée, équilibres diagonaux, rôle de la convention de tie-breaking explicité)
• Le claim « équilibre unique » restreint à r > 1 (ou qualifié)
• Réexécution du notebook (C.2) + sorties cohérentes

See #12208 (Chantier 5) — révélé par la review de #15437.