feat(usage): add Grok and OpenCode reporting - #5704

💭 Looking at the changed files to understand the Effect usage patterns. The main files involved are UsageService.ts and usageOpenCode.ts—the latter is a pure helper module working with Node APIs and Promises, while UsageService.ts is where Effect.promise gets used. I need to examine the actual implementation to spot any convention violations. I'm checking whether usageOpenCode.ts as a pure Promise-based helper module violates the conventions—it follows the same pattern as the existing usageTranscriptReader.ts, so it's consistent with how the codebase already handles these utilities. Now I need to verify if the new code in UsageService.ts is accessing process.env directly within the Effect service, which the conventions discourage. I need to check whether reading process.env.GROK_HOME directly in the Effect service violates the repo's conventions around hidden dependencies, so I'm looking at how other providers handle environment variables in server code and whether there's an established pattern for this. I'm noticing that the codebase uses direct process.env access as a pattern, and the Grok resolver does the same without injectable parameters. I should check if GrokProvider.ts already has a home directory resolver function to avoid duplication, though this doesn't seem to violate any established conventions. Now I'm wondering whether resolveOpenCodeDataDir is duplicating existing functionality. Looking at the imports and patterns: usageOpenCode.ts correctly uses named imports from contracts, UsageService imports pure helper functions (not a service module), and the existing error handling with Cause.squash is already in place. The web state uses hooks and Atom without Effect.promise, which is fine. The Effect.promise pattern in readOpenCodeDatabaseRecords matches what's already there, and the function safely catches all errors and returns null. The OpenCode SQLite reader does blocking sync operations in an async context, which is a performance consideration but not a convention issue. I should verify the contracts and shared module imports are using the right patterns. This PR doesn't involve creating or refactoring Effect services, just adding providers, so I'm checking whether the touched code follows the conventions. The imports look properly namespaced, there are no new errors, and I don't see ManagedRuntime, runPromise, or Layer.succeed being added. One concern though: resolveGrokSessionsDir is reading from process.env directly inside the service's make function, which could be hiding dependencies in module globals or closures rather than properly declaring them. However, the repo already accepts this pattern for environment defaults, and the OpenCode resolver follows the injectable approach, so this is more of a style inconsistency than a convention violation. The UsageProviderKind additions would be a type-completeness concern if any exhaustive maps weren't updated elsewhere, but that's outside the scope of this Effect conventions check—the type system would catch missing entries anyway. Everything checks out against the listed conventions, so this is a success.