fix(chat): hand off a chatless send when the probe is superseded

The previous commit made a superseded probe leave the entry queued rather than
re-send it. That is the right retry for a chat-bound key, which is the stable
chat id, but wrong for a chatless one: a `pending::` key is regenerated every
mount, so anything left under it is unreachable and the message is stranded —
the same loss this PR exists to prevent, just reached by a different route.

A superseded probe on a pending key now goes through the same recovery lanes as
the cleanup-abort path (live replacement surface, else a one-shot stored
handoff), still carrying the stream id so the next surface probes before it
sends. Skipped when the entry is no longer under that key, since adoption
migrating it to a live chat already leaves it recoverable there. The lane is
extracted so both call sites share one implementation.

The existing superseded test only asserted that nothing sent, which this bug
satisfied trivially; it now also asserts the message survives. Confirmed red
without the fix.

Author: waleedlatif1

apps/sim/app/workspace/[workspaceId]/home/hooks/use-chat.mount-send.test.tsx

@@ -519,6 +519,13 @@ describe('useChat remount send recovery', () => {
         await sleep(3000)
       })
       expect(state.postCalls).toBe(postsBeforeUnmount)
+
+      /* Not sending is only half of it — the message must still be
+         recoverable. A chatless surface's `pending::` key is regenerated per
+         mount, so leaving the entry there would strand it just as surely as
+         re-sending would have duplicated it. */
+      expect(MothershipHandoffStorage.consume('ws-1')?.message).toBe('do not zombie me')
+      expect(allQueuedMessages()).toHaveLength(0)
     })
 
     it('re-sends when the server has no stream for it', async () => {

apps/sim/app/workspace/[workspaceId]/home/hooks/use-chat.ts

@@ -4586,6 +4586,30 @@ export function useChat(
         useMothershipQueueStore.getState().remove(dispatchChatKey, msg.id)
       }
 
+      /**
+       * Hands a chatless send to whatever surface comes next, because its
+       * `pending::` queue key is regenerated per mount and anything left under
+       * this one is unreachable. Prefers the live replacement surface's
+       * listener and falls back to a one-shot stored handoff for a real
+       * navigation away. Both lanes carry attachments and the stream id, so the
+       * next surface probes before it sends.
+       */
+      const handOffChatlessRecovery = (recoverStreamId?: string) => {
+        if (
+          !sendMothershipMessage(msg.content, msg.contexts, msg.fileAttachments, recoverStreamId)
+        ) {
+          MothershipHandoffStorage.store(
+            {
+              message: msg.content,
+              ...(msg.contexts?.length ? { contexts: msg.contexts } : {}),
+              ...(msg.fileAttachments?.length ? { fileAttachments: msg.fileAttachments } : {}),
+              ...(recoverStreamId ? { recoverStreamId } : {}),
+            },
+            workspaceId
+          )
+        }
+      }
+
       const restoreQueuedMessage = (handoff?: QueuedSendHandoffSeed, recoverStreamId?: string) => {
         const recoverableCleanupAbort = recoverStreamId !== undefined
         if (!handoff) {
@@ -4613,19 +4637,7 @@ export function useChat(
            Chat-bound sends keep the queue restore — their key is the stable
            chat id — and carry the stream id on the restored entry. */
         if (recoverableCleanupAbort && dispatchChatKey.startsWith(PENDING_CHAT_KEY_PREFIX)) {
-          if (
-            !sendMothershipMessage(msg.content, msg.contexts, msg.fileAttachments, recoverStreamId)
-          ) {
-            MothershipHandoffStorage.store(
-              {
-                message: msg.content,
-                ...(msg.contexts?.length ? { contexts: msg.contexts } : {}),
-                ...(msg.fileAttachments?.length ? { fileAttachments: msg.fileAttachments } : {}),
-                ...(recoverStreamId ? { recoverStreamId } : {}),
-              },
-              workspaceId
-            )
-          }
+          handOffChatlessRecovery(recoverStreamId)
           return
         }
         useMothershipQueueStore.getState().insertAt(dispatchChatKey, originalIndex, {
@@ -4658,9 +4670,26 @@ export function useChat(
            adopt its chat instead when it exists. */
         if (liveMsg.recoverStreamId) {
           const probe = await resolveRecoveredSendChatId(liveMsg.recoverStreamId, options.epoch)
-          /* Unknown, not "safe to send" — leave the entry queued (it keeps its
-             `recoverStreamId`) so the next mount's drain probes again. */
-          if (probe.status === 'superseded') return
+          /* Unknown, not "safe to send". A chat-bound key is the stable chat
+             id, so leaving the entry queued IS the retry — the next mount's
+             drain probes again. A chatless `pending::` key is regenerated per
+             mount, so the same move would strand the message under a dead key;
+             hand it to the recovery lanes instead, still carrying the stream
+             id. Skipped when the entry is no longer under this key (adoption
+             migrated it to a live chat), where it is already recoverable. */
+          if (probe.status === 'superseded') {
+            if (dispatchChatKey.startsWith(PENDING_CHAT_KEY_PREFIX)) {
+              const queueStore = useMothershipQueueStore.getState()
+              const stillUnderDeadKey = (queueStore.queues[dispatchChatKey] ?? []).some(
+                (queued) => queued.id === msg.id
+              )
+              if (stillUnderDeadKey) {
+                queueStore.remove(dispatchChatKey, msg.id)
+                handOffChatlessRecovery(liveMsg.recoverStreamId)
+              }
+            }
+            return
+          }
           if (probe.status === 'adopted') {
             removeQueuedMessage()
             adoptResolvedChatId(probe.chatId, {