fix(server): respect inherited OPENCODE_CONFIG_CONTENT - #4242

💭 Looking at this change, there's a helper function being added that reads from process.env as a default parameter. The concern here is whether this violates the principle of not hiding dependencies in module globals — since the service is directly accessing environment variables in its constructor rather than having them injected explicitly. I'm checking whether reading process.env directly in the service implementation violates the conventions around hiding dependencies in module globals, and whether Effect has a better pattern like Config or Environment for this. Let me see if the codebase already uses process.env elsewhere or if there's an established convention I should follow. The env ?? process.env pattern is idiomatic throughout this codebase, so that's not a style violation. The pure helper function uses named exports which aligns with the conventions, and the test file imports from "vite-plus/test" consistently with the rest of the repo. Since this is a behavior change rather than just a refactor, focused tests are needed and they're already in place. No new error classes, service definitions, or runtime changes are introduced. The helper placement before error declarations is a minor stylistic choice but not a clear violation of the canonical ordering. Everything checks out, so the response should reflect success.