feat(daemon): add workspace management RPC

[slkzgm]

Part of the optional remote backend mode RFC (see #54). This extends the daemon introduced in #58 with workspace management endpoints needed by the UI in remote mode.

What's included

• Add JSON-RPC methods to manage workspaces via the daemon:
  • list_workspaces
  • add_workspace
  • add_worktree
  • connect_workspace
  • remove_workspace / remove_worktree
  • update_workspace_settings / update_workspace_codex_bin
  • list_workspace_files
• Forward CODEX_HOME when spawning worktree sessions (keeps legacy .codexmonitor behavior consistent with local mode).

Notes

• No behavior change for the default local mode; daemon remains optional.
• Backend-only change; follow-up PR(s) will wire these calls from the UI when backendMode = remote.

Related

• feat(settings): add remote backend configuration #70 adds the app-level settings for selecting/configuring the remote backend (opened in parallel).

Testing

• cargo test (in src-tauri)

[Dimillian]

Deep review feedback:

Findings:

• High: add_worktree checks only local branches. For remote-only branches, it will create a new local branch off current HEAD (via git worktree add -b <branch>), which can point at the wrong commit. Consider checking refs/remotes or using git show-ref --verify refs/remotes/<remote>/<branch> + git worktree add <path> <remote>/<branch> or git worktree add -b <branch> <path> <start-point>.
• Medium: remove_workspace/remove_worktree remove sessions first, then run git worktree remove. If that git command fails, the function returns early and leaves workspaces/workspaces.json unchanged but sessions already gone. That creates a persistently inconsistent state. Consider deferring session removal until after git succeeds, or handle failures by restoring state + surfacing error.
• Medium: ensure_worktree_ignored appends to tracked .gitignore, which can dirty repos or fail on read-only repos. Consider .git/info/exclude or a best-effort ignore that doesn’t mutate tracked files.
• Low: unique_worktree_path returns an existing path if 2..999 are taken, so the subsequent git call fails with a generic error. Consider returning an error when no available path is found.

Open questions:

• Should remote-tracking branches be supported, or is “new branch from HEAD” intended?
• Is modifying .gitignore acceptable for daemon-managed worktrees?

[slkzgm]

Thanks for the deep review! I pushed a follow-up addressing all findings and clarifying the intent.

add_worktree (remote-tracking branches)

• Now checks for refs/remotes/origin/<branch> first (then other remotes) and uses an explicit start-point: git worktree add -b <branch> <path> <remote>/<branch>.
• If no local branch and no remote-tracking ref is present, it keeps the previous behavior (creates a new branch from current HEAD).

remove_workspace/remove_worktree (consistency)

• Session teardown is now deferred until after git worktree remove succeeds.
• remove_workspace no longer returns early in a way that can persist inconsistent state; it removes successful child worktrees, persists those removals, and keeps the parent workspace if any child removal fails (returns a summarized error).

.gitignore mutation

• Worktrees are now created under the daemon --data-dir (<data_dir>/worktrees/<parentId>/...), aligning with the local-mode “worktrees in app data” approach and avoiding mutations to tracked .gitignore / read-only repos.

unique_worktree_path

• Now errors explicitly if no free path can be found (instead of returning an existing path and letting git fail generically).

Let me know if you’d prefer changing the fallback behavior to error instead of creating a new branch from HEAD when the branch doesn’t exist locally/remotely — I kept the existing behavior to avoid breaking expectations.