[BUG] Desktop (SSH): "Worktree location" accepts only a local path, so remote sessions always fall back to the remote $HOME

**Summary**

Desktop has a single "Worktree location" setting and it resolves against the **local**
filesystem — on Windows, a local Windows path. There is no way to enter a path on an SSH
remote. So for SSH sessions the setting can never hold a usable value, and every remote
worktree lands in the remote user's home directory at
`$HOME/-<16 hex>//`, regardless of what the setting says.

A Windows path and a Linux remote path cannot both live in one field. The setting is
structurally unusable for SSH sessions.

**Steps to reproduce**

1. Desktop on Windows. Settings → Claude Code → Worktree location: the field offers a local
Windows path only; there is no way to specify a path on an SSH host.
2. Add an SSH connection to a Linux host and open a repository on it as the session folder.
3. Start a new session with the **worktree** option selected.

**Expected**

Some way to say where worktrees go on that remote host — and, with the setting at its default,
worktrees at `/.claude/worktrees/` on the remote.

**Actual**

The worktree is created under the remote `$HOME`, nowhere near the project:

```
$HOME/myrepo-a8ae6b289e243a34/
├── .claude-managed-worktrees
├── session-one-bea3e2
├── session-two-0d2256
└── session-three-3bde66
```

Nothing is written to `/.claude/worktrees/` on the remote.

The app writes a marker file into that home directory, `.claude-managed-worktrees`, which
points at the setting as the reason it chose the location — a setting that cannot be given a
remote value:

> This directory holds Claude Code session worktrees placed here by the
> claude-ssh daemon (the "Worktree location" setting). Its subdirectories are
> managed checkouts; open the repository itself, not one of them, as a
> session folder. Safe to delete once the directory is otherwise empty.

**Not caused by the remote OS**

The remote is Fedora Atomic, where `/home` is a symlink to `/var/home`, so the symlink
refusals documented for worktree creation are the obvious suspect. They are not the cause:

- The fallback root the app chose, `$HOME/myrepo-/`, is itself under that symlink and
works fine — three worktrees in it, all healthy and registered.
- The repository root is already symlink-free (`/var/home/...`), so the default location
resolves to a path with no symlink in it to refuse.
- Both spellings normalize: session records are stored under the `/var/home` form, and the
CLI's own containment check realpaths both sides before comparing, so the two spellings are
never compared as strings.

**No workaround**

- **A remote value in the setting**: not expressible. The field is local-filesystem only.
- **Per-connection setting**: none. `sshConfigs` entries accept `id`, `name`, `sshHost`,
`sshPort`, `sshIdentityFile` only.
- **Settings file on the remote**: no key at any scope. `worktree.*` accepts `baseRef` and
`bgIsolation` only, so the remote host's own `~/.claude/settings.json` can't override it.
- **`WorktreeCreate` hook**, the documented way to relocate worktrees: not called by Desktop —
#29716, open since 2026-03-01.
- **Creating worktrees manually with git** and opening each as a session folder: doesn't scale
(this repository runs 107 registered worktrees), and for the documented default location the
SSH folder picker can't open hidden directories anyway — #93909.

**Asks**

Any one of these unblocks it:

1. Let the worktree location be set per SSH connection, entered as a remote path.
2. Accept a value relative to the project root, so one setting resolves correctly on every host
regardless of platform.
3. Failing a setting, have SSH sessions use the documented default
`/.claude/worktrees/` on the remote rather than the remote `$HOME`.

**Environment**

- Desktop app: Claude Code Desktop on Windows
- Remote host: Fedora Linux 44 (Atomic), kernel 7.2.4
- `ccd-cli` on remote: 2.1.271
- Claude Code CLI on remote: 2.1.274

Related: #27282 (configurable worktree location), #29716 (`WorktreeCreate` not called in
Desktop), #93909 (SSH folder picker can't open `.claude/worktrees`)

The issue names the Desktop Worktree location setting, SSH connection configuration, the WorktreeCreate hook, and the remote .claude/worktrees path, but no source files or tests. Start by tracing SSH worktree creation and how that setting is resolved; done means a supported remote or project-relative location is honored instead of falling back to the remote $HOME.

Written by the indexing model from the issue text.