Met en cohérence le calcul par dotation pour /commune et /calculate

• Correction d'un crash.
• Détails :
  • Corrige une erreur de type sur requête à /commune suite à une évolution de /calculate
    • Incohérence introduite en fin de MR à l'origine de la v2.0.0
  • Aligne le type de chaque commune type de UiDisplayedImpacts.casTypes de /calculate sur ApiCommuneResponse de /commune

---

Contexte

Régression détectée en local par une erreur "commune non suscriptable" :

curl -X POST http://127.0.0.1:8000/commune -H 'Content-Type: application/json' -d @init_commune_denestanville.json | jq

Et en pré-prod par la réponse :

{
  "nomCommune": "string",
  "codeInseeCommune": "string",
  "codeInseeDepartement": "string",
  "nombreHabitants": 0,
  "potentielFinancierParHabitant": 0,
  "summaryDotations": [
    {
      "dotation": "string",
      "eligible": true,
      "montantDotation": 0
    }
  ],
  "error": "string"
}

La source en est l'utilisation de la même méthode format_commune_impact pour /commune et /calculate mais avec des inputs typé différemment :

En développant /calculate, le traitement des résultats pour les cas types de communes a apporté un changement de syntaxe vers codeInseeCommune = str(commune["codeInseeCommune"]) mais pour /commune, commune étant du type ApiCommuneRequest ou ApiCommuneResponse, il n'est pas "suscriptable".

Inversement codeInseeCommune = str(commune.codeInseeCommune) ne fonctionnait pas pour /calculate car le type de casType était une list sans plus de précision et donc une liste de dictionnaires au final. On obtenait AttributeError: 'dict' object has no attribute 'codeInseeCommune'

Cette MR précise donc le type de UiDisplayedImpacts.casTypes: list[ApiCommuneResponse] sachant qu'il est identique pour la requête /calculate et pour la response. On choisit donc ApiCommuneResponse qui est le plus complet (et où les attributs propres à la response sont optionnels)