fix(core): update stale project worktree when directory is moved

[cyrasafia]

Supersedes #38682, which was auto-closed when its head branch was renamed.

Issue for this PR

Closes #35240
Related #30697 #30005 #30015 #23248

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

When a project directory is moved or renamed on disk, Project.fromDirectory kept the stale worktree path in the project table forever. The root cause is that the upsert in fromDirectory unconditionally reused existing.worktree for non-global projects:

worktree: projectID === ProjectV2.ID.global ? worktree : existing.worktree,

This meant reopening the project from its new location never updated the stored path, causing the desktop app and TUI to display and navigate to the old (now-dead) path.

Fix: Before reusing the stored worktree, check whether it still exists on disk via fs.existsSafe. If the path is gone (project was moved/renamed), use the freshly resolved path instead. If the path still exists, the existing value is preserved — this is important for the linked-worktree accumulation behavior verified by the "should accumulate multiple worktrees in sandboxes" test, where opening a second worktree must NOT overwrite the primary worktree.

How did you verify your code works?

• Added a new test "updates worktree when project directory is moved" that creates a git repo, moves the directory via mv, reopens from the new path, and asserts worktree is updated while the project ID stays the same.
• Verified the existing linked-worktree accumulation test still passes (both paths exist on disk, so the stored worktree is preserved).
• Ran bun typecheck and bun test test/project/project.test.ts test/project/project-directory.test.ts test/project/migrate-global.test.ts — all 49 tests pass.

Screenshots / recordings

N/A — server-side data layer change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found several related PRs that address similar concerns about handling moved/relocated projects:

Potentially Related PRs:

1. fix(opencode): recover projects moved to a new path #38584 - fix(opencode): recover projects moved to a new path

   • Directly addresses project relocation and recovery

2. fix(core): relocate moved project checkouts #34142 - fix(core): relocate moved project checkouts

   • Related to the same issue of handling moved project directories

3. fix(desktop): handle moved projects and deleted paths #34137 - fix(desktop): handle moved projects and deleted paths

   • Desktop app handling of moved projects, likely interacts with the core fix

4. fix (core): Multiple clones of same repo are different projects #35311 - fix(core): Multiple clones of same repo are different projects

   • May relate to project identity and directory handling

The PR mentions it supersedes #38682 (which was auto-closed). The key difference here is that PR #39056 focuses on updating the stale worktree path in the database when a project directory is moved, while some of the related PRs above may address recovery and relocation at different layers (opencode, desktop, etc.).

[cyrasafia]

Closing in favor of #38584, which was submitted earlier and covers a strict superset of this change.

Both PRs fix the same root cause (the stored worktree path going stale when a project directory is moved/renamed), but #38584 is the more complete solution:

• It introduces Project.resolveDirectory to recover the moved directory before Git discovery, preventing FileSystem.realPath failures at startup.
• It routes InstanceStore.load/reload/dispose through resolveDirectory so the stale and live paths share one valid instance cache key.
• It maintains a directoryAliases map so repeated stale requests keep resolving.
• It migrates matching project and legacy-global sessions (including relative path) and workspace directories to the recovered path, without changing time_updated.

#39056 only updates the worktree field during the fromDirectory upsert when the stored path no longer exists. That behavior is already included in #38584's replaceWorktree logic, making this PR functionally a subset of the earlier one.

Thanks for the contribution!