Bug: `open_workspace` treats leading `~` as a relative path instead of expanding `$HOME`

[MJRT]

Version

v1.1.0-beta.4

win11 + wsl2 Ubuntu

Summary

open_workspace advertises support for a leading-tilde home path such as ~/project, but passing such a path currently treats ~ as a literal relative path component.

For example:

{
  "path": "~/devspace",
  "mode": "checkout"
}

fails with an error equivalent to:

Path is outside allowed roots: $HOME/~/devspace

Using the equivalent absolute path succeeds:

{
  "path": "$HOME/devspace",
  "mode": "checkout"
}

This appears to be a regression in path normalization / allowed-root resolution rather than unsupported input: the open_workspace tool contract explicitly documents leading-tilde paths, and existing workspace path resolution is expected to support home-directory expansion.

Reproduction

1. Configure $HOME or a directory below it as an allowed root.
2. Call:

open_workspace(
  path = "~/devspace",
  mode = "checkout"
)

3. Observe that the resolved path contains a literal ~:

$HOME/~/devspace

4. Call the same tool with the expanded absolute path:

open_workspace(
  path = "$HOME/devspace",
  mode = "checkout"
)

5. The workspace opens successfully.

Expected behavior

A leading ~ is expanded to the current user's home directory before absolute-path normalization and allowed-root containment checks:

~/devspace
→ $HOME/devspace

The expanded path should then go through the same normal containment and workspace validation as an explicitly supplied absolute path.

Actual behavior

The input is resolved as though it were an ordinary relative path:

~/devspace
→ $HOME/~/devspace

and is subsequently rejected as outside the allowed roots.

Invariants

• ~/... and the equivalent $HOME/... path resolve to the same workspace.
• Home expansion happens before allowed-root containment checks.
• Existing containment guarantees remain unchanged after expansion.
• Ordinary relative paths continue to resolve using their existing semantics.
• Paths outside configured allowed roots remain rejected.
• ~user/... does not need to be supported unless DevSpace already defines that syntax.

Regression coverage

Add coverage demonstrating that:

open_workspace("~/project")

and:

open_workspace("$HOME/project")

resolve to the same checkout workspace when that location is allowed.

The regression test should also verify that tilde expansion does not provide a way to bypass allowed-root containment.

Related context

Issue #106 already describes home-directory path expansion as behavior supported by the existing path resolver, so this should be treated as restoring the documented path contract rather than introducing new path syntax.