8f88cb0030
Race nach Etappe-3-Reconnect-Fix: lokale failed-Bubble (mit clientMsgId) und Server-Backup-Eintrag (ohne clientMsgId, aus alter Bridge-Version) landeten beide im Merge → User sah Doppelpost: einmal ueber der ARIA-Antwort (Server), einmal mit Retry-Knopf darunter (lokal). Plus ACK-Timer konnte weiterlaufen obwohl die Bubble schon delivered war — Retry pushte den Status zurueck auf sending und nach 30 s auf failed. App: - chat_history_response-Merge faellt zusaetzlich auf text+timestamp- Heuristik im 5-Min-Fenster zurueck wenn die Server-Bubble keine clientMsgId hat → lokale Kopie wird verworfen, kein Doppelpost - messagesRef + dispatchWithAck prueft vor Send/Retry ob die Bubble bereits delivered ist → kein verspaetetes failed mehr - ARIA-Reply cleart ALLE laufenden ACK-Timer (Bridge hat unsere Messages ja offensichtlich verarbeitet) Docs: - issue.md: neuer Block 'Chat-Stabilitaet' mit den drei Etappen + beiden Race-Fixes; AsyncStorage-Race-Punkt aus 'Offen' abgehakt - README.md: Chat-Such-Zeile aktualisiert (highlight statt filter), Jump-to-Bottom + Delivery-Status-Bubbles dokumentiert Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>