[Feature] Allow relocating a workspace to a new directory, preserving its sessions

[gujunhk]

Summary

There is currently no way to change the directory a workspace points to. The workspace path is fixed at creation time via fs.realpath and is treated as the workspace's identity — WorkspaceEntity exposes setTitle but no setPath, and the workspace domain's workspaces table keys uniqueness on the canonical path string.

This becomes a problem in a very ordinary situation: the project directory moves on disk. Moving a repo from C:\ to D:\ because the system disk is full, renaming a top-level folder, or moving a checkout to another drive are all everyday events. Today the only options are:

1. Remove the workspace and re-add the new path — but the re-added project starts with an empty session list, so every past session loses its grouped home and shows up as "Ungrouped".
2. Leave the stale registration in place — it points at a path that no longer exists.

Neither preserves the session-to-project grouping the user built up.

ChatGPT, Cursor, and similar tools treat the project folder as a mutable attribute of the project. It would be reasonable for DSH to offer the same.

Proposed behavior

Expose a workspace "relocate" (or "change path") operation with roughly these semantics:

• Takes a new absolute directory path; validates it exists and is a directory (same rule as create).
• Requires the target path not to already be owned by another workspace (the canonical-path uniqueness invariant is preserved).
• Updates the workspaces record's path and stamps updatedAt, keeping the same workspaceId, title, display order, and — critically — the existing sessionIds ordering.
• Re-validates session membership against the new path where possible. Sessions that ran in the old path can't have their stored cwd rewritten, so this needs a decision: either keep them accounted (they keep their grouping, as the "missing paths retain recorded ownership" rule already allows) or offer an explicit opt-in to re-point sessions whose cwd was exactly the old workspace path to the new one.
• Surfaces in the GUI, e.g. a "Change folder…" entry in the workspace context menu next to Rename and Delete.

Why not just delete and re-add?

Deleting and re-adding is documented to start "fresh" — the old sessions do not come back automatically. For a user with dozens of sessions in a project that is exactly the loss they are trying to avoid by relocating rather than recreating.

Additional context

• Related: no existing Discussion covers this. The closest are #47 (Chinese path names) and #65 (disk root as workspace), which are different problems.
• The pendingMutation marker machinery and the serialized operation chain in WorkspaceRegistry seem like a reasonable fit for a two-write relocate, mirroring how create and delete are handled.
• Workspace registration does not imply ownership of the directory, so a relocate operation only needs to update the registration — no filesystem move is required, and no destructive action is involved.