fix(server): avoid slow checkpoint index rebuilds - #8538

💭 I'm checking the diff for GitVcsDriver.ts and its test file to understand the existing conventions before making changes.

1. browse_code — apps/server/src/vcs/GitVcsDriver.ts

2. browse_code — apps/server/src/vcs/GitVcsDriver.ts

💭 I'm checking whether using Node's built-in fs module directly in the test mock violates the service conventions, but since it's confined to a test file rather than production code, it seems reasonably acceptable.

3. browse_code — apps/server/src/vcs/GitVcsDriver.test.ts

💭 The makeVcsDriverShape naming is pre-existing in the repo, not introduced by this PR, so I shouldn't flag it against the convention. I'm now checking the error handling around the empty tree oid case in the production code. I'm scanning for new error classes or convention violations—no new ones introduced, and the use of Effect.ignore and Effect.orElseSucceed swallows failures but doesn't clearly violate the documented error-modeling conventions. I also check for disallowed patterns like Layer.succeed, ManagedRuntime.make, or bare runPromise calls, finding none, and note the test file suppresses a node-builtin-import diagnostic that isn't explicitly covered by the stated conventions. Since the behavior change is accompanied by proper tests and there's no misuse of error-handling combinators like catchIf or catchTag, I conclude there are no real findings. That means the check should report success with something like "All clear" as the title and summary, formatted as the required JSON output rather than literal text.