fix(server): thread delete no longer fails on already-removed worktrees - #8076

💭 I want to check the current state of the file since the previous run flagged raw stderr being logged directly, and now it seems to log stderr length instead.

1. git_tools — apps/server/src/vcs/GitVcsDriverCore.ts 01fc7d2..ca99366

💭 I'm double-checking that the GitCommandError construction is fine without an underlying cause, then verifying that executeGitWithStableDiagnostics, pruneWorktrees, and fileSystem are properly in scope. I also want to confirm gitCommandContext normalizes arguments rather than leaking raw command details into the error.

2. git_tools — executeGitWithStableDiagnostics|function gitCommandContext|const gitCommandContext|const pruneWorktrees|pruneWorktrees =

💭 I'm checking that pruneWorktrees being declared after removeWorktree isn't a temporal dead zone issue since it's only invoked at runtime after module setup completes, so that's fine. Now I'm considering whether logging the filesystem path in that message counts as sensitive data, and it seems acceptable since conventions treat resource paths as stable domain context rather than sensitive info. Now I want to check whether gitCommandContext includes command arguments, so I'm looking at lines 383-400 to verify.

3. browse_code — apps/server/src/vcs/GitVcsDriverCore.ts

💭 That error detail looks fine as a static string. Now I want to verify that fileSystem is properly in scope within makeGitVcsDriverCore, pulled in via the FileSystem service.

4. git_tools — fileSystem = yield*|import * as|from "effect"

💭 I'm checking that the test file properly imports the FileSystem and Path namespaces used in the diff, and confirming GitCommandError still uses the existing TaggedErrorClass definition unchanged. Also verifying that Effect.orElseSucceed and Effect.logWarning are valid usages here.

5. browse_code — apps/server/src/vcs/GitVcsDriverCore.test.ts

💭 All conventions are satisfied and the previously flagged issue is fixed, so there are no new findings. Since the output format requires JSON rather than plain text, I'll set the state to success with an appropriate title rather than just writing "All clear".