feat: add cross-platform voice supervisor - #6206

💭 The PR is too large to review all at once, so I need to get a file list first. I'll try using the GitHub API to fetch the list of changed files with pagination, since my earlier attempt with stat_only seemed to be ignored and returned the full diff instead.… The catchTag issues in those voice files have been resolved, so that's cleared up. Now I'm checking the shim files to see if they have similar problems, but the diff is too large to review efficiently—I need to pull a smaller file list through the API instead.… I'm focusing on Effect service conventions in this large PR—the previous run flagged 5 items I need to verify have been fixed and check for any new violations. Rather… Findings 1 and 2 are resolved, and finding 5 is also addressed since voiceHttp.ts now uses plain Effect.fn helpers instead of a VoiceEnvironmentClient service. Now I'm checking the new Effect service modules introduced in this PR—specifically OpenAiRealtime.ts, OpenAiRealtimeCredential.ts, and ElectronSystemPreferences.ts—to see if they follow the naming conventions. ElectronSystemPreferences wraps a native Electron API adapter, taking a plain object with methods that return native values or Promises rather than Effects. The service uses Layer.effect with HostProcessPlatform and imports Electron directly, which matches the standard pattern for other Electron services in the codebase. There's an extra makeService const between make and layer, but that's acceptable. I'm also checking whether the convention about not encoding the same distinction twice with both a specific error tag and a single-value operation is being violated here.… The OpenAiRealtimeCredentialError looks standard with operation and reason fields, where the message is derived from operation alone. Now I'm checking the client-side voice files in apps/web/src/voice — specifically looking for those previously flagged shim files realtimeEvents.ts and voiceTools.ts. The directory listing shows voicePanelStore, voiceStartDefaults, voiceSupervisorHost, voiceSupervisorStore, and voiceToolsRep instead. Good — those shims are gone. Since I can't diff against the previous commit, I need to review the full scope of changed files for Effect service conventions,… I'm looking at how this composition function bridges the Effect runtime into the React component layer, using runPromise at the application boundary where the promise-based host dependency connects to the Effect system.… The web usage looks good since it's all contained within React components. Now I need to check the server side for any improper uses of catchTag or Layer.succeed in the new services under apps/server, and see if there are other Effect service refactors in the changed files. Getting the full list of changed files is tricky with pagination, so I'm… The packages diff shows the client-runtime voice modules are plain TypeScript controllers rather than Effect services, so the typical Effect conventions don't really apply here. I'm noticing that voiceHttp.ts is exported under the subpath "./state/voice" even though the actual filename is voiceHttp.ts — though that's not a convention violation based on the file layout rules.… Looking at the web-side architecture, those shim files I mentioned earlier have been removed, but the adapter pattern persists through realtimeSession.ts and voiceSupervisorStore.ts, which re-export from the underlying runtime libraries to layer in browser-specific implementations like transport and state management.… Looking at the latest commit to see what's changed since the previous review, then checking whether there are any remaining violations in… Looking at the last commit to see what changes were made to handle supervisor edge cases, and verifying there are no remaining Effect.catchTag calls in the voice-related code. I've already reviewed all the desktop app changes across the affected files. Now I need to check the mobile app scope in apps/mobile/src/** for any new Effect service definitions in the voice modules, and double-check that I've covered all the modified desktop files. Then I'll evaluate the remaining findings, particularly around ElectronSystemPreferences.ts where the make function passes pure configuration and native APIs, and whether the ElectronMicrophoneAccessError class should be split into separate error types based on how the reason discriminator determines the user-facing message. I'll skip flagging this since I already reviewed the file without raising concerns, and the guidance discourages repeating issues. The cause field is deliberately redacted for security reasons, which conflicts with flagging it as a convention violation. Now I'm checking the touched code for Effect.catchIf with schema predicates and error factory helpers — specifically looking at the voice/http.ts file where there are helper functions that construct errors with a reason parameter and pull the traceId from context. These aren't simple pass-through factories, so they should be fine. The failRateLimiter function in OpenAiRealtime.ts does real classification work between different error types, and redactVoiceRequestError performs actual normalization, so both are legitimate. There's a pointless switch statement in updateVoiceCredential with identical branches, but that's a code-quality issue, not a convention problem. I'm also noticing that isEnvironmentVoiceHttpError is a private Schema.is constant, and the convention expects these to be exported directly.…