fix(store): exempt contacts with message history from MED-2 eviction

On a busy TCP/transport attachment the destinations table churns past the
1000-row cap fast. Eviction keyed purely on lastSeen, so an un-favorited
contact you were actively conversing with could be deleted mid-conversation
— taking its public key with it — leaving the chat stuck on "(unknown
sender)" and unable to send until the peer re-announced.

Add `hash NOT IN (SELECT contactHash FROM messages)` to the eviction
subquery on both platforms (Room DAO + SQLDelight .sq), alongside the
existing favorite / userLabel / hidden exemptions. Message-history contacts
are bounded by real conversations, so the table stays well under the
CursorWindow limit the cap protects. Regression test added in
StorageRoundTripTest (real SQLite via Robolectric).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: thatSFguy

androidApp/src/main/kotlin/io/github/thatsfguy/reticulum/android/storage/Daos.kt

@@ -71,6 +71,19 @@ internal interface DestinationDao {
      * deleted) rows already don't count toward the visible list
      * but are excluded here too so the eviction doesn't churn
      * them. Audit reference: 2026-05-13 MED-2.
+     *
+     * Contacts with message history are also exempt
+     * (`hash NOT IN (SELECT contactHash FROM messages)`): on a busy
+     * TCP/transport attachment the table churns fast, and a contact
+     * you're actively conversing with — but haven't favorited — was
+     * being evicted out from under an open conversation, dropping its
+     * public key so the chat reverted to "(unknown sender)" and
+     * couldn't send until the peer re-announced. Like favorites, these
+     * are real user state. They don't count toward [keepCount], so the
+     * effective table size is (favorites + labeled + message-history) +
+     * up to [keepCount] announce-only rows; message-history contacts
+     * are bounded by actual conversations, so this stays well under the
+     * CursorWindow limit the cap was lowered to protect. Set 2026-06-24.
      */
     @Query("""
         DELETE FROM destinations
@@ -79,6 +92,7 @@ internal interface DestinationDao {
             WHERE favorite = 0
               AND hidden = 0
               AND (userLabel IS NULL OR userLabel = '')
+              AND hash NOT IN (SELECT contactHash FROM messages)
             ORDER BY lastSeen DESC
             LIMIT -1 OFFSET :keepCount
         )

androidApp/src/test/kotlin/io/github/thatsfguy/reticulum/android/storage/StorageRoundTripTest.kt

@@ -74,6 +74,39 @@ class StorageRoundTripTest {
         assertTrue(ordered.any { it.hash == "starred" })
     }
 
+    /**
+     * Regression (2026-06-24): MED-2 announce-flood eviction must NOT
+     * delete a contact you have message history with, even when it's
+     * the oldest-by-lastSeen and un-favorited. Before the
+     * `hash NOT IN (SELECT contactHash FROM messages)` guard, a busy
+     * TCP mesh could evict an active conversation's destination row,
+     * dropping its public key so the chat reverted to "(unknown
+     * sender)" and couldn't send until the peer re-announced.
+     */
+    @Test fun evictionSparesContactsWithMessageHistory() = runTest {
+        val dest = db.destinationDao()
+        val msg = db.messageDao()
+        // Oldest + un-favorited, but we've exchanged a message with it.
+        dest.upsert(makeDestination(hash = "withmsg", lastSeen = 100, favorite = false))
+        msg.insert(MessageEntity(
+            contactHash = "withmsg", direction = "incoming", content = "hi",
+            title = "", timestamp = 1L, state = "verified",
+            attempts = 0, lastAttempt = 0, lastError = null,
+            rawPacket = null, packetHash = null, rssi = null,
+        ))
+        // Two newer announce-only rows with no message history.
+        dest.upsert(makeDestination(hash = "noMsgOld", lastSeen = 101, favorite = false))
+        dest.upsert(makeDestination(hash = "noMsgNew", lastSeen = 300, favorite = false))
+
+        // Keep only the newest 1 of the *evictable* (no-history) rows.
+        dest.evictUnfavoritedOldest(keepCount = 1)
+
+        assertNotNull(dest.get("withmsg"),
+            "contact with message history must survive eviction despite being oldest + unfavorited")
+        assertNotNull(dest.get("noMsgNew"), "newest evictable row is kept")
+        assertEquals(null, dest.get("noMsgOld"), "oldest evictable row with no history is evicted")
+    }
+
     @Test fun messageInsertAndPartialUpdate() = runTest {
         val dao = db.messageDao()
         val id = dao.insert(MessageEntity(

shared/src/commonMain/kotlin/io/github/thatsfguy/reticulum/engine/ReticulumEngine.kt

@@ -750,9 +750,14 @@ class ReticulumEngine(
      * MED-2 announce-flood eviction. We let `destinationRepo` grow
      * up to [MAX_DESTINATIONS] non-favorited rows; past that
      * threshold each subsequent announce evicts the oldest excess
-     * by `lastSeen` ASC. Favorited contacts and user-renamed entries
-     * are exempt — those are deliberate state the user shouldn't
-     * lose to flood pressure. Eviction is throttled to every
+     * by `lastSeen` ASC. Favorited contacts, user-renamed entries,
+     * and **any contact with message history** are exempt — those are
+     * deliberate state the user shouldn't lose to flood pressure. (The
+     * message-history exemption was added 2026-06-24: an un-favorited
+     * contact you were actively chatting with on a busy TCP mesh could
+     * be evicted mid-conversation, dropping its public key so the chat
+     * reverted to "(unknown sender)" and couldn't send until the peer
+     * re-announced.) Eviction is throttled to every
      * [EVICTION_INTERVAL_ANNOUNCES] new announces so a busy mesh
      * doesn't run the DELETE on every packet (Room/SQLDelight handle
      * the DELETE cheaply, but skipping it most of the time is

shared/src/commonMain/sqldelight/io/github/thatsfguy/reticulum/storage/ReticulumIosDatabase.sq

@@ -116,13 +116,19 @@ DELETE FROM destinations;
 -- non-favorited, non-user-labeled, non-hidden rows past
 -- the keep count. Favorites and renamed entries are preserved
 -- regardless. Audit reference: 2026-05-13 MED-2.
+-- Contacts with message history are also exempt
+-- (hash NOT IN messages.contactHash): an un-favorited contact you're
+-- actively conversing with was being evicted on a busy mesh, dropping
+-- its public key so the chat reverted to "(unknown sender)" and
+-- couldn't send. Like favorites, that's real user state. Set 2026-06-24.
 evictUnfavoritedOldest:
 DELETE FROM destinations
 WHERE hash IN (
     SELECT hash FROM destinations
     WHERE favorite = 0
       AND hidden = 0
       AND (userLabel IS NULL OR userLabel = '')
+      AND hash NOT IN (SELECT contactHash FROM messages)
     ORDER BY lastSeen DESC
     LIMIT -1 OFFSET ?
 );