[Bug] SSH remote workspace with a path identical to a local project shadows the local project

提交前确认 · Pre-submission checklist

• 我已搜索过现有 issue，确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
• 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

文件 / 项目操作 · File / Project ops

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

严重程度 · Severity

影响体验 · Major (功能可用但体验受损 / works but degraded)

复现频率 · Reproducibility

必现 · Always

问题描述 · Description

SSH remote workspaces are matched against local projects by bare absolute path string. When the remote folder's path is byte-identical to a local project's path (which happens naturally when both hosts share the username), the remote workspace entry permanently shadows the local project: opening the local project resolves to the remote workspace, and after an app restart the remote entry becomes the first tab and auto-reconnects on every launch. The workspaceIdentity string (remote:ssh:host:port:user:path) already encodes host/port/user, but workspace/tab resolution and project_id derivation ignore it.

复现步骤 · Steps to reproduce

1. Have a local project at /home/<user>/Projects/<repo>.
2. Connect a session over SSH to a host where the same user has the project at the identical absolute path (e.g. both machines use /home/<user>/Projects/<repo>).
3. Restart the app.

期望表现 · Expected behavior

• Local and remote workspaces with identical paths remain distinct workspaces.
• Workspace/tab resolution (and remote session project_id) should key on workspaceIdentity — which already encodes host/port/user — instead of the bare path.

实际表现 · Actual behavior

• Opening the local project resolves to the remote workspace.
• After restart, the remote entry is at index 0 of the workspace list and auto-reconnects on every launch.
• ~/.zcode/v2/setting.json → lastWorkspaceSession ends up holding two entries with the same workspacePath:

{ "kind": "remote",
  "workspacePath": "/home/<user>/Projects/<repo>",
  "localWorkspacePath": "/home/<user>/Projects/<repo>",
  "workspaceIdentity": "remote:ssh:<host>:22:<user>:/home/<user>/Projects/<repo>",
  "lastConnectionStatus": "connected" },
{ "kind": "local",
  "workspacePath": "/home/<user>/Projects/<repo>",
  "workspacePurpose": "project" }

• In the session DB (~/.zcode/cli/db/db.sqlite, table session), project_id is derived from the path alone (proj_home-<user>-projects-<repo>), so the SSH-attached session is filed under the same project_id as the local project, mixing local and remote history.

ZCode 版本 · ZCode version

3.11.2 (desktop client; remote server component auto-deployed, was 3.10.2)

设备 / 系统 / 浏览器 · Device / OS / Browser

Desktop (Electron) on Arch Linux x64; remote target: Linux x64 over SSH, same username on both hosts

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

Log evidence (redacted):

[zcode-host] connecting window-scoped remote source, target=ssh:<user>@<host>:22
[remote] ZCode agent spawn preflight { workspaceKey: 'remote:ssh:<host>:22:<user>:/home/<user>/Projects/<repo>',
  requestedCwd: '/home/<user>/Projects/<repo>', cwd: '/home/<user>/Projects/<repo>', cwdExists: true }

Workaround: keep remote projects under a path prefix that can never exist locally (e.g. ~/remote-projects/<repo>); to recover a shadowed local project, close the app and remove the kind: "remote" entry from lastWorkspaceSession in ~/.zcode/v2/setting.json.

Start by tracing workspace/tab resolution and remote session project_id derivation, using workspaceIdentity as the key and comparing the entries in ~/.zcode/v2/setting.json with the session table in ~/.zcode/cli/db/db.sqlite. Done means local and SSH workspaces with identical paths remain distinct, the local project opens locally, and restarting does not place or reconnect the remote workspace in its place.