Desktop app: sessions that ran in a git worktree can't be resumed after restart — app silently rebinds the conversation to a new empty session, orphaning the transcript

Environment

• Claude desktop app 1.24012.9 (macOS, Darwin 25.3.0, arm64)
• Bundled Claude Code engine 2.1.219 (transcript stores also touched by standalone CLI 2.1.220)

Summary

Transcripts for sessions that work inside a git worktree (.claude/worktrees/<name>) are filed under a worktree-derived project key in ~/.claude/projects/, but the desktop app resolves a conversation's transcript from the window folder's key. The mismatch is invisible while the engine process is alive. On the first resume after the engine dies (e.g. app relaunch):

1. The send fails with No conversation found with session ID: <id>.
2. A banner appears: "Session history unavailable — this session's conversation history is no longer on disk."
3. If the user presses Try again / Start fresh / re-sends, the app silently rebinds the conversation record's cliSessionId to a brand-new empty session. The original transcript is never deleted — just orphaned — but from the user's perspective, weeks of context vanish with no way back in-app.

Reproduction

1. In the desktop app, start a conversation in folder F; have the session do its work inside a git worktree (fork-with-worktree, or EnterWorktree).
2. Quit the app (engine process dies).
3. Reopen, open that conversation, send any message.
4. Observe the error; press Try again → conversation is now bound to a fresh empty session. The real transcript still sits at ~/.claude/projects/<key-derived-from-worktree-path>/<old-id>.jsonl.

Evidence from an affected machine

• App record ~/Library/Application Support/Claude/claude-code-sessions/<acct>/<org>/local_<uuid>.json showed cliSessionId changed from the original id to a fresh one after retry; cwd = window folder.
• Original transcript intact (32 MB, 7,167 lines) under -<...>-<repo>--claude-worktrees-<name>/.
• The fresh stub jsonl begins with a queue-operation enqueue of the exact retried user message.
• 11 worktree-keyed transcript folders on this machine: every historical worktree session shares the latent condition; only the ones the user tried to resume broke. Two long-running conversations were lost the same afternoon this way.

Expected behavior

• Transcript resolution should follow the transcript (also search worktree-derived keys, or re-home the file to the origin key on worktree entry/exit or session end).
• The app should never silently rebind a titled conversation to an empty session. At minimum, preserve the previous cliSessionId in the record so in-app recovery stays possible.

Manual workaround (verified, lossless)

Stop the stub's engine process, rewrite the orphaned jsonl's top-level sessionId fields to the newly-bound stub id, place it at the stub's path, copy the session's sidecar dir (subagents/, tool-results/), restart the app. Full history returns.

Possibly related: #33912 (CLI --resume returns "No conversation found" with files present; closed).