Desktop app's "Resume a session" dialog finds zero sessions after migrating project folders to a new path (CLI --resume finds them fine)

**Environment**
- Claude Desktop app, Windows, installed as an MSIX/Store package (package family name `Claude_pzs8sxrjxfjjc`)
- Bundled Claude Code version: 2.1.260 (also present: 2.1.258)
- OS: Windows 11 Pro
- Native CLI install (`~/.local/bin/claude.exe`) was missing/broken (`claude doctor` flagged it); repaired via `claude install`. Bug persists after repair + full app restart.

**What happened**
I migrated ~11 Claude Code projects to a new machine. The project root's drive letter ended up changing (from what would have been `D:\Claude Code` to `C:\Claude Code`). I correctly renamed the matching session-history folders under `~/.claude/projects/` to match the new hashed path (e.g. `C--Claude-Code-CyB-Avicola`), and confirmed the `.jsonl` transcripts inside are valid, uncorrupted, and match the exact session IDs from before the move.

In the desktop app's **Code** tab, opening any of these folders shows only sessions created after the migration (via the app itself). The **"Reanudar una sesión" / Resume a session** dialog (triggered by `/resume` or its icon), with **"Todas las carpetas" / All folders** selected and the **Estado / Status** filter set to **"Todo" / All**, reports:

> "No se encontraron sesiones de Claude Code en esta computadora." (No Claude Code sessions were found on this computer.)

...even for a folder that has a valid, non-empty, correctly-placed transcript file.

**What I expected**
The dialog should list all valid sessions found under `~/.claude/projects/` for the current folder (or all folders, in "All folders" mode).

**Isolating the bug**
To rule out data corruption, I ran a byte-level validation of every `.jsonl` line in all 23 session files across the 11 migrated projects (including a 144 MB one) — 100% valid JSON, no corruption.

To rule out a CLI-level resume problem, I repaired the native standalone install (`claude install`, since it was missing) and ran the **native, non-packaged** `claude.exe --resume` directly from inside one of the same project folders (outside the packaged app entirely). It found the historical session immediately, with the correct title, size, and age, and successfully resumed it with full content.

So: the underlying data and the core resume/session-discovery logic both work correctly. The bug appears isolated to the **packaged desktop app's own session-listing feature** (both the per-folder sidebar list and the "Resume a session" dialog) — it seems to not be looking in the same place the CLI resolves for `~/.claude/projects`. My guess (unconfirmed) is that this may be related to how MSIX/Store packaging redirects `%APPDATA%\Claude` for the packaged process vs. how the renderer resolves paths for its own session index — but I don't have visibility into the app's internals to confirm.

**Repro steps**
1. Have a project with existing Claude Code session history under `~/.claude/projects//`.
2. Move the project folder to a different path such that the drive letter or a higher-level path segment changes.
3. Rename the corresponding `~/.claude/projects/` folder to the new hash matching the new path (so the folder-name-to-path mapping is correct).
4. Open the (new-path) folder in the Claude Desktop app's Code tab.
5. Trigger "Resume a session" → "All folders".
6. Result: no sessions found, despite valid transcripts on disk for that exact path.

**Workaround found**
Running the native `claude.exe --resume` (or `-c`) directly from a terminal in the project folder works correctly and finds/resumes the migrated sessions.

Compare the packaged Desktop Code tab and Resume a session flow with the native claude.exe --resume entry point. Start by checking how the packaged app resolves ~/.claude/projects/ and reads the .jsonl transcripts after a project move. Done means migrated sessions appear in the per-folder list and All folders resume dialog while native CLI behavior remains intact.

Written by the indexing model from the issue text.