Git command errors discard stderr, making failures opaque to callers

Problem

executeGit in apps/server/src/vcs/GitVcsDriverCore.ts records only stderrLength on a failed git command and sets detail to a static fallback string (fallbackErrorDetail ?? "Git command exited with a non-zero status."). The actual stderr text is dropped, so every downstream consumer of GitCommandError sees an opaque message with no way to recover the cause.

Concrete example

While testing the worktree MCP tools (#3754), git worktree add failed because the requested branch already existed and was checked out in another worktree. Git's stderr said exactly that. What surfaced instead was:

Git command failed in GitVcsDriver.createWorktree (<cwd>): git worktree add failed

Diagnosing it required manually re-running the git command outside the app. Any git precondition failure (branch exists, path exists, stale worktree metadata, permissions, missing ref) collapses into the same string.

Suggested fix

Keep the structural fields as they are, but carry a bounded, useful signal on GitCommandError, for example:

• a stderrExcerpt capped at a few hundred bytes, or
• a parsed reason enum for common git failures (ref exists, path exists, not a repository, permission denied), with the excerpt as fallback.

If dropping stderr is deliberate (telemetry hygiene, path leakage), a capped and sanitized excerpt on the in-process error object only, excluded from telemetry serialization, would still fix the developer experience without changing what leaves the machine.

Start by reading executeGit in apps/server/src/vcs/GitVcsDriverCore.ts and trace GitCommandError through its consumers and telemetry serialization. Done means failed git commands preserve a bounded, useful stderr signal for in-process callers while retaining the existing structural fields and avoiding unintended telemetry or path leakage.