fix(desktop): clear the stale stream target on the assistant-tail append path too

Sibling site of the idle-resume rule from the stale-fold fix: the
assistant-tail append exit (user row persisted, no projection row) still
carried the journal's streamId onto a not-running resume, which kept the
journal entry alive (persistInFlightTurnState only clears when streamId is
null) and re-folded the same tail on every open. Apply the same
keepPending gate and pin it with a regression assertion.

Refs #85308

apps/desktop/src/lib/inflight-turn-journal.test.ts

@@ -577,6 +577,9 @@ describe('recoverInFlightTurnJournal', () => {
 
     expect(result.applied).toBe(true)
     expect(result.messages.map(m => m.id)).toEqual(['db-u1', 'assistant-stream-1'])
+    // Idle resume: the assistant-tail append path must not resurrect the
+    // stream target either, or the journal entry re-folds on every open.
+    expect(result.streamId).toBeNull()
     const tail = result.messages.at(-1)!
     expect(tail.pending).toBe(false)
     expect(tail.parts[0]).toMatchObject({ type: 'tool-call' })

apps/desktop/src/lib/inflight-turn-journal.ts

@@ -797,7 +797,11 @@ export function mergeInFlightMessages(
       applied: true,
       caughtUp: false,
       messages: [...baseMessages, ...withoutBaseIds(tailAssistants, baseMessages)],
-      streamId,
+      // Same idle-resume rule as the other exit paths: only a running turn
+      // keeps the stream target alive. Carrying the stale streamId here kept
+      // the journal entry alive (persistInFlightTurnState only clears when
+      // streamId is null), so the same tail was folded again on every open.
+      streamId: options.keepPending ? streamId : null,
       turnStartedAt: null
     }
   }