Fix stale chat reloads overwriting selected thread

[cursor]

Bug and impact

A completed send in conversation A could reload A after the user had already switched to conversation B. Because loadActiveThread only checked a global sequence number and not the active conversation, A's reload could invalidate B's in-flight load and render the wrong transcript under B's selected thread. This could look like lost chat history and lead users to reply in the wrong context.

Root cause

loadActiveThread incremented loadSeq and applied messages/briefing/anchors without verifying that the loaded conversation still matched activeConversationIdRef.current. Its finally also always cleared threadLoading, even when a newer thread load owned the loading state.

Fix

• Guard thread loads before and after IPC against the current active conversation.
• Track the load sequence that owns threadLoading so stale loads cannot clear a newer load's spinner.
• Update the active conversation ref synchronously when switching/clearing/restoring threads.
• Add a Vitest regression test that reproduces the cross-thread send/reload race.

Validation

• npm test -- src/hooks/useChat.test.tsx (passes; jsdom prints a canvas getContext warning from imported chart code)
• npm test (passes; same jsdom canvas warning)
• npm run build (passes; existing large chunk warning)