fix(desktop): avoid double-quoting the SSH update mutex path on remote hosts

[twotnguyen]

Summary

When connecting to a remote host over SSH, withRemoteUpdateMutex wrapped mutexPath in shq() even though mutexPath was already the output of expandRemotePath() (which already produces a shell-quoted string or "$HOME"'/…' fragment).

On remote Linux hosts, the extra shq() passed literal single-quote characters inside sys.argv[1] to the Python mutex helper. When Python evaluated os.path.dirname(sys.argv[1]) on a path like '/home/hermes/.hermes/…', it treated the path as relative because it began with ' instead of /. Calling os.makedirs(parent, exist_ok=True) then created a literal directory named ' under the user's home directory (e.g. /home/hermes/').

Changes

• In apps/desktop/electron/remote-lifecycle.ts, embed mutexPath directly into withRemoteUpdateMutex's command string instead of wrapping it in shq(mutexPath).
• In apps/desktop/electron/remote-lifecycle.test.ts, add regression test buildSpawnCommand does not double-quote the update mutex path asserting that both absolute and tilde hermesHome paths produce clean python3 -c ... <path> arguments without double-quoting or literal single quotes.

Fixes #99133

[bmgskr2025]

Thanks!

[SZWzz]

Heads-up on overlap: this fixes the same withRemoteUpdateMutex double-quoting site as #96260 (and #96187).

Whichever one lands fixes the quoting fault, so no argument from me either way — but for whoever reviews: #96260 covers this same one-line mutex change plus two adjacent correctness defects in the same spawn chain that the one-line fix alone leaves behind:

• the published lockfile pid is a JSON string ("__PID__" substituted unquoted), while readLockfile requires an integer and the reuse regex only matches "pid":<digits> — so every fresh spawn's ownership record is malformed;
• the detached setsid/nohup shell echoed $! from both the inner and outer shells, so $child captured a two-line value and the sed substitution was invalid under POSIX sh (now guarded: non-integer $child fails closed with exit 76).

It also pins the contract with argv-level regression tests (asserting the exact argv the remote python receives, under dash), which is the gap that let this site regress silently in the first place — the existing cmd.includes(...) assertions pass under both the broken and fixed forms.

Happy to rebase/adjust if a maintainer prefers to land a minimal one first.

[kshitijk4poor]

Thanks @twotnguyen — this is the right fix for the right line (#99133's root cause), and it was verified live: the composed spawn command run through a real sh hands python sys.argv[1]="'/home/hermes/.hermes/.hermes-update-in-progress.mutex'" on origin/main, and the clean path once shq() is dropped.

Closing in favour of #104206, which carries the same one-line change from #96187 (@koltyj, filed 27 Aug — earliest of the three PRs on this site) with cherry-pick authorship, plus its test that parses the command with a real sh rather than regex-matching the string. SZWzz's overlap note above is correct: whichever lands fixes the fault; first-filer gets the credit. Your report and analysis are referenced in the PR body. If #104206 fails to land for any reason this reopens.