[BUG] Desktop: sessions from a folder whose path is a string prefix of a sibling (MyApp vs MyApp-MR) are grouped under the shorter project and resume against the wrong folder

## Summary

In the Claude Desktop app (Code tab), sessions belonging to a project folder whose path is a **string prefix** of a sibling folder's path get grouped under the shorter-named project, and resuming one of them targets the wrong folder.

Layout that triggers it — two independent clones, different branches, different working state:

```
~/projects/MyApp <- branch A
~/projects/MyApp-MR <- branch B
```

`~/projects/MyApp` is an exact string prefix of `~/projects/MyApp-MR`.

## Expected

Sessions opened in `~/projects/MyApp-MR` stay grouped under a `MyApp-MR` project, and resuming one opens with `MyApp-MR` as the primary working directory.

## Actual

Sessions were opened and worked in `~/projects/MyApp-MR` one day. On returning the next day:

1. They appeared grouped under the **`MyApp`** project in the sidebar, not `MyApp-MR`.
2. They pointed at the `~/projects/MyApp` folder — a different branch with different working-tree state.

This is the dangerous part: the two folders are different checkouts of the same repo, so a resumed session looks plausible while reading and potentially editing the wrong tree. Nothing in the UI flagged the switch.

## Evidence: the persisted data is correct, so this is display/resolution-layer

I inspected the on-disk state after the fact. All of it is correctly separated:

- Two distinct transcript directories exist and are correctly populated: `~/.claude/projects/-Users-me-projects-MyApp-MR/` and `~/.claude/projects/-Users-me-projects-MyApp/`.
- Every `"cwd"` field in every `-MyApp-MR` transcript is `/Users/me/projects/MyApp-MR`. No entry points at the other folder. The reverse also holds.
- No cross-writes between the two sets of transcripts. One `-MyApp-MR` file had a later mtime than its last prompt, but the appended lines were only `{"type":"custom-title"}` and `{"type":"mode"}` metadata.
- `~/.claude.json` has both `/Users/me/projects/MyApp` and `/Users/me/projects/MyApp-MR` as separate `projects` keys.
- The app's own session index reports the correct `cwd` for all six `-MR` sessions.

So the grouping shown in the sidebar disagreed with every persisted record of these sessions' working directory.

## Suspected cause

A path comparison somewhere in project grouping / cwd resolution that uses a plain prefix test without requiring a trailing path separator — e.g. `path.startsWith(projectPath)` rather than `path === projectPath || path.startsWith(projectPath + sep)`.

Under that logic `/Users/me/projects/MyApp-MR` matches the `/Users/me/projects/MyApp` project, and the group's folder resolves to the shorter path. That accounts for both symptoms at once (wrong group *and* wrong target folder) and for the persisted data being untouched.

The same hazard applies to the encoded directory keys, where `-Users-me-projects-MyApp` is a prefix of `-Users-me-projects-MyApp-MR`.

## Reproduction

1. Create two sibling folders where one name is a prefix of the other: `~/projects/MyApp` and `~/projects/MyApp-MR`. Git clones on different branches make the consequence visible.
2. Open sessions in the Desktop app against **both** folders, so both project groups exist.
3. Have some conversations in the `MyApp-MR` sessions.
4. Quit and reopen the app the next day.
5. Observe which project group the `MyApp-MR` sessions appear under, and which folder they resolve to on resume.

I hit this after an app restart with a day in between, so it may depend on how groups are rebuilt at startup rather than reproducing on every launch.

## Impact

Real risk of reads and edits landing in the wrong checkout of the same repository, silently. `foo` / `foo-MR`, `foo` / `foo-old`, `foo` / `foo-2`, `api` / `api-v2` are all common conventions for exactly the case where you keep two trees of one project side by side — which is also the case where writing to the wrong one is hardest to notice.

## Suggested handling

Beyond fixing the comparison: when a session resumes with a primary working directory different from the one recorded in its transcript, say so in the UI rather than resuming silently. That turns this class of bug from silent-wrong-repo into a visible prompt.

## Environment

- Claude Code in the Claude Desktop app (Code tab), macOS (Darwin 25.6.0), Apple Silicon
- App version:
- Model: Opus 5
- Both folders are independent clones, not git worktrees (`git worktree list` shows a single entry in each)

## Related issues

These look adjacent but describe different layouts, and both were closed as duplicates without a linked canonical thread:

- #55034 — sessions grouped under the wrong project; sibling services under a shared parent, reporter suspects parent-folder matching rather than prefix matching
- #56688 — primary working directory locked to a folder other than the one selected; the two folders are unrelated rather than prefix-related
- #69105 — grouping generally disconnected from working directory

Start in the Claude Desktop app's Code tab and trace project grouping and cwd resolution during startup and session resume; reproduce with sibling paths such as MyApp and MyApp-MR. Compare the recorded cwd with the selected project, then verify that grouping and resume preserve the exact folder and flag any mismatch in the UI.

Written by the indexing model from the issue text.