chore(gitignore): stop tracking local IdeA tickets state

.ideai/tickets/31/issue.md

@@ -1,31 +0,0 @@
----
-id: "83d320f1-766b-4744-b518-8e39a2518e9c"
-number: 31
-title: "Détection de profils séquentielle : N × 800 ms au pire, résultat potentiellement partiel"
-status: "closed"
-priority: "low"
-sprint: "e28a4d53-8bd2-446a-b0ac-2a017373b8b2"
-links: [{"target":"#28","kind":"relatesTo"}]
-agentRefs: []
-createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
-updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
-createdAt: 1783491197541
-updatedAt: 1784064442657
-version: 4
----
-## Origine
-Relevé par Git en revue du diff du ticket #28 (merge 710fa8f), hors périmètre du fix.
-
-## Constat
-Depuis #28, `DetectProfiles::execute` séquence les `await` candidat par candidat, chaque sonde bornée par `tokio::time::timeout(800ms)`. N profils indisponibles coûtent donc **N × 800 ms** au pire.
-
-Côté frontend, `DETECT_TIMEOUT_MS = 3 s` relâche le flag `detecting`. À partir de ~4 candidats muets, le tour de détection dépasse ce délai : l'indicateur « Detecting… » disparaît avant que les résultats n'arrivent.
-
-## Impact
-Cosmétique. L'UI **ne gèle plus** (c'est bien l'objet de #28, corrigé) ; le risque résiduel est un affichage de disponibilité qui arrive après la retombée de l'indicateur.
-
-## Piste de fix
-Paralléliser les sondes avec `futures::future::join_all` dans `DetectProfiles::execute` (`crates/application/src/agent/usecases.rs`) : le coût au pire retombe à ~800 ms quel que soit N, largement sous le timeout UI.
-
-## Validation
-Test `#[tokio::test(flavor = "multi_thread")]` sur `DetectProfiles::execute` avec N candidats muets, asserting que la durée totale reste bornée par ~1 × timeout et non N ×.