fix(desktop): stop the submit drift guard from aborting every new chat

[jquesnelle]

The #54527 context pin (7acaff5) snapshots the selected stored session and route token at submit entry and aborts when either changes mid-flight. But a NEW chat's create pipeline legitimately moves both: on success, createBackendSessionForSend re-homes selection and navigates to the chat it just minted. Judged against the pre-create draft baseline that read as a user switch, so every first send of a new chat aborted before prompt.submit — message dropped, no DB row persisted (row creation is lazy, server-side in prompt.submit), and the window stranded on a route whose REST reads 404 "Session not found" forever.

Fix: after a successful create, verify no one re-homed during create's post-commit await via the active-session ref (a non-null return guarantees create set it; every switch path retargets it synchronously), then re-pin the drift baseline to the created chat. A mid-create switch still aborts through create's own null return, or through the active-ref check for the post-commit window. Re-pinning also restores the correct stored-id association for the optimistic-message state updates, which the pinned pre-create null had degraded.

Tests: red-first regression for the new-chat send, an abort case for a switch landing in create's post-commit window, and the sleep/wake new-chat stub made faithful to the real create (it sets the active ref before returning — the inert stub is what let this ship green).

[OutThisLife]

tested manually in broken state and this fixed it for me. i was following a similar path @ #63611 so may merge as a fast follow.

[alt-glitch]

This was generated by AI during triage.

Competing OPEN PR for the #54527 new-chat first-message regression (tracked in #62481). Cluster: #62482 (earliest — likely canonical), #63502, #63486, #63310, and this PR — all re-baseline the session-context drift guard after createBackendSessionForSend so the guard no longer trips on the submit's own new-session side effect. Related, not a duplicate: independent competing fixes at the same site with slightly different mechanisms. Flagging for a human to pick the canonical one to merge and close the rest.

[OutThisLife]

Selected as the canonical fix for the #54527 / #62481 new-chat first-message drift-abort regression — reproduced and confirmed fixed locally, and it ships a red-first regression test for exactly this path (createBackendSessionForSend succeeds, then the #54527 drift guard aborts before prompt.submit).

This also explains the widely-reported "have to send a prompt twice in the Desktop app" behavior (#62569, #63036): the first send creates the session then aborts before prompt.submit, so the second send — now with a non-null activeSessionId — skips create, doesn't trip the guard, and lands.

Closing the competing fixes at the same site as duplicates in favor of this one: #62482, #63502, #63486, #63310. Also closing #63611 (aimed at a different, unconfirmed reconnect-drop edge — wrong root for this symptom).