bug: v0.4.21 daemon breaks MSYS path translation on Windows (C:\c\Users\...)

Bug Description

Multica CLI v0.4.21 introduces a regression in MSYS path translation on Windows. The daemon translates POSIX-style paths like /c/Users/... to C:\c\Users\... instead of the correct C:\Users\..., causing all tasks to fail with GetFileAttributesEx errors.

This bug does not exist in v0.4.20 or v0.4.19.

Reproducibility

100% reproducible on my environment. Every task launched under v0.4.21 daemon fails with this error. Downgrading to v0.4.20 immediately fixes the issue.

Environment

• OS: Windows 10 (x64)
• Username: <username> (ASCII, no CJK characters)
• Shell: Git Bash (MSYS2)
• Multica CLI: v0.4.20 (working) vs v0.4.21 (broken)
• Daemon profile: desktop-api.multica.ai

Error Logs

All errors occur during prepare task temp dir — the daemon tries to stat a file at the wrong path:

23:24:27 ERR task failed task=2b4a05ba error="prepare task temp dir: GetFileAttributesEx C:\c\Users\<username>\...: The system cannot find the path specified."
23:29:03 ERR task failed task=aba3212a error="prepare task temp dir: GetFileAttributesEx C:\c\Users\<username>\...: The system cannot find the path specified."
23:48:33 ERR task failed task=c7c4b8d5 error="prepare task temp dir: GetFileAttributesEx C:\c\Users\<username>\...: The system cannot find the path specified."
00:14:52 ERR task failed task=b16fa306 error="prepare task temp dir: GetFileAttributesEx C:\c\Users\<username>\...: The system cannot find the file specified."

Note the path: C:\c\Users\... — the /c/ prefix from MSYS is being incorrectly translated to C:\c\ instead of being stripped to yield C:\Users\....

Impact

Under v0.4.21, every single task fails with this error. The daemon is completely unusable on Windows. I had to:

1. Kill all daemon processes
2. Restore v0.4.20 binary from a cached copy
3. Lock the binary as read-only (chmod 444) to prevent auto-update from overwriting it
4. Add --no-auto-update --no-auto-reload flags to the start script

Additional Issues in v0.4.21

• WebSocket disconnects: use of closed network connection
• Auto-update download timeouts: context deadline exceeded
• Temp dir cleanup failures: file locked by another process

Workaround

Pin to v0.4.20 and disable auto-update:

multica.exe daemon start --foreground --profile <profile> --no-auto-update --no-auto-reload

Suggested Investigation

The MSYS path translation likely changed between v0.4.20 and v0.4.21 in the Go code that converts POSIX paths to Windows paths. The relevant translation logic converts /c/Users/... to C:\Users\... but v0.4.21 appears to produce C:\c\Users\... instead (the /c/ drive prefix is not being stripped before prepending C:).

Happy to provide full daemon logs or test a patched build.

Start by locating the Go MSYS path-translation logic in the daemon and comparing its behavior between v0.4.20 and v0.4.21 on Windows with Git Bash. Reproduce the prepare task temp dir failure using /c/Users/...; done means it resolves to C:\Users\... and tasks no longer fail with GetFileAttributesEx.