Cowork Dispatch: `start_code_task` cannot target WSL2 workspaces — rejects `wsl:` keys, mistranslates absolute Linux paths to `C:\`

## Summary

Dispatch's `start_code_task` tool appears to have no WSL 2 code path. Every path format
that could identify a WSL-resident workspace fails, each in a different way:

- the canonical `wsl::` key → `cwd must be an absolute path`
- an absolute Linux path → silently mistranslated to `C:\home\...` → `no longer exists`
- a UNC path (`\\wsl.localhost\...`) → rejected outright

This is inconsistent with Claude Code Desktop's **Code tab**, which ships documented,
first-class WSL 2 support (environment picker → WSL section → distro → folder picker
browsing inside the distribution).

## Environment

| | |
|---|---|
| Windows | 11, Version 10.0.26200.8875 |
| WSL | WSL 2, `Ubuntu-22.04` (Ubuntu 22.04.5 LTS) |
| Kernel | 6.6.87.2-microsoft-standard-WSL2 |
| Claude Code CLI (inside WSL) | 2.1.220 |
| Claude Desktop | 1.24012.9 (03c61d) |
| Repo location | `/home//dev/` — inside the distro's filesystem |

## Reproduction

Ask Dispatch to start a coding task against a repo that lives in the WSL filesystem.
Three `cwd` formats attempted, three distinct failures:

| # | `cwd` passed to `start_code_task` | Result |
|---|---|---|
| 1 | `\\wsl.localhost\Ubuntu-22.04\home\\dev\` | Rejected outright — UNC paths not accepted |
| 2 | `wsl:ubuntu-22.04:/home//dev/` | `cwd must be an absolute path` |
| 3 | `/home//dev/` | Mistranslated to `C:\home\\dev\`, then failed as `no longer exists` |

**Attempt 3 is the most diagnostic.** A leading `/` is being resolved against the Windows
drive root, which means the validator is applying Windows path semantics with no awareness
that a WSL target is even possible. Attempt 2 shows the canonical WSL workspace identifier
is not recognized as a valid `cwd` shape at all.

## The same workspace works in the Code tab

A WSL 2 session against this exact folder starts and runs correctly from the **Code tab**
(environment picker → WSL → `Ubuntu-22.04` → project folder). The session footer confirms
the resolved target — distro `Ubuntu-22.04`, the project folder, with git branch and
worktree controls active.

So on one machine, in one application, against one folder: the Code tab resolves the WSL
workspace correctly, and Dispatch cannot address it at all. The defect is in Dispatch's
`cwd` handling — not in WSL, the distribution, trust state, or the workspace record.

## The workspace is already registered and trusted

This is not a discovery, registration, or trust problem. The Windows-side
`%USERPROFILE%\.claude.json` `projects` map **already contains the canonical WSL key**,
written by Claude Desktop itself:

```json
{
"projects": {
"C:/Users//dev/": { "hasTrustDialogAccepted": true },
"wsl:ubuntu-22.04:/home//dev/": { "hasTrustDialogAccepted": true },
"C:\\Users\\\\dev\\": { "hasTrustDialogAccepted": true }
}
}
```

The identifier Dispatch would need is sitting in the config file. Dispatch simply has no
code path that consumes it.

_Minor secondary observation: the duplicate `C:/…` and `C:\…` keys pointing at the same
directory suggest path normalization is inconsistent in whatever writes this map._

## Expected behavior

`start_code_task` should accept the same `wsl::` workspace
identifier Claude Desktop already persists to `.claude.json`, and launch the session
inside the distribution — the same way the Code tab's WSL environment picker does.

## Impact

The Code tab documents WSL 2 support, but Dispatch cannot reach it. For developers whose
repositories live inside the WSL filesystem — the configuration Anthropic's own
documentation recommends — Dispatch is unusable from mobile.

From [the WSL docs](https://code.claude.com/docs/en/desktop-wsl):

> Use a WSL session when your repository lives inside the distribution's filesystem.
> Working on those files from Windows goes through a network filesystem, which is slow
> and breaks file watching; running the session inside the distribution avoids both.

The only available workaround is maintaining a second, Windows-side clone. That
reintroduces precisely the performance and file-watching problems the WSL documentation
warns about, and adds a permanent sync burden between two copies of the same repo.

## Related issues

- **#38276** — requested Cowork/Dispatch/remote-session support on Linux and WSL2. Closed
as *not planned / invalid* with the note "Issue doesn't seem to be related to Claude
Code", and no substantive response. Given the Code tab ships documented WSL 2 support
and this failure is in a Claude Code tool's `cwd` validator, that triage looks incorrect.
- **#49933** — native WSL remote integration for Claude Code Desktop (open). Overlaps on
the underlying platform gap but does not cover Dispatch or `start_code_task`.

## Suggested fix

Smallest viable change: teach the `start_code_task` `cwd` validator to recognize the
`wsl::` form and route it to the WSL session launcher the Code tab already
uses.

Failing that, accept absolute POSIX paths alongside an explicit distro parameter — rather
than silently resolving a leading `/` against `C:\`, which turns a valid Linux path into a
confusing "no longer exists" error.

Start at the `start_code_task` entry point and its `cwd` validator; compare its handling with the Code tab's WSL session launcher. Use the three reproduced `cwd` forms and the existing `wsl:ubuntu-22.04:/...` key in `%USERPROFILE%\.claude.json` as inputs, and verify that a task launches in the distro rather than translating the path to `C:\`.

Written by the indexing model from the issue text.