fix(server): resolve Claude SDK executable path on Windows npm installs - #3740

💭 I'm examining the new ClaudeExecutable.ts file to check for Effect service convention violations. The module introduces an injectable service ClaudeExecutableFileCheck using Context.Reference and exports a function to resolve the Claude SDK executable path. The imports follow proper namespace conventions with subpath imports from effect and Node modules. Now I'm checking whether the named imports from @t3tools/shared/hostProcess and @t3tools/shared/shell should be namespace imports instead. The convention allows named imports when accessing service tags from external packages, so this appears acceptable. I need to dig deeper into how ClaudeExecutableFileCheck is being used as a dependency injection seam and whether it violates any core conventions. Looking at isExistingFile - it's a synchronous file check wrapped in a Context.Reference with a defaultValue, which serves as a test seam. This is actually a legitimate callback strategy rather than a hidden dependency in a Layer implementation, so it should be fine. Similarly, SpawnExecutableResolution is a service used in tests that returns the resolved command, which follows the same pattern. The resolveClaudeSdkExecutablePath function takes pure configuration inputs (binaryPath and environment) and uses Effect.fn to yield services from the environment, which is correct. The warning log includes file paths in its payload, which aren't sensitive data, so that's acceptable. Now I need to trace through how SpawnExecutableResolution is actually defined and used to verify there's no real violation here. Looking at the key requirement about applying checks when a pull request creates or consumes an Effect service—this module introduces a Context.Reference service called ClaudeExecutableFileCheck, but it's not a full service module with the typical Context.Service, make, and layer exports. It's more of a helper module that provides utilities. I should examine how other modules in the codebase handle similar patterns, particularly looking at the shared/shell and hostProcess modules to understand the conventions better.

1. github_api_read_only — Show me the definition of SpawnExecutableResolution in @t3tools/shared/shell and HostProcessPlatform in @t3tools/shared/hostProcess. How are they defined as Effect services (Context.Reference, Context.Tag, Context.Service)? Provide the full source.

💭 The ClaudeExecutableFileCheck follows the established pattern for Context.Reference services with default values, which aligns with how the codebase handles these dependencies. The module's use of namespace imports for effect modules and named imports for service references is consistent with existing conventions, so this is a valid test seam. Now I need to review the changes in ClaudeAdapter.ts and ClaudeProvider.ts to check for any violations. The ExecutableFileCheck callback is a valid test seam pattern, and the imports follow the codebase conventions—these are service tags where named imports are acceptable. I should verify how existing code imports these same modules to ensure consistency.

2. github_api_read_only — How is HostProcessPlatform from @t3tools/shared/hostProcess and SpawnExecutableResolution from @t3tools/shared/shell imported by other consumers in apps/server (named import vs namespace import)? Show example import statements from existing files.

💭 The import style aligns with the rest of the codebase, and the new module follows the same Context.Reference pattern as existing ones. The service tag mirrors the naming conventions of similar tags, and there are no violations of the error handling or dependency injection patterns used throughout.