perf(mobile): compressed websocket frames for iOS - #4794

💭 Looking at the changed files to see how they align with Effect service conventions. The main files are the native WebSocket wrapper and runtime setup—the WebSocket implementation is a plain class around a native module, while runtime.ts is where Effect and Layer come into play. Let me check the imports to understand the structure better. I'm checking whether using ManagedRuntime.make at the application boundary in runtime.ts is acceptable—it is, since that's where the framework meets the app. The main structural changes involve creating a plain adapter class for the native WebSocket and then setting up a webSocketConstructorLayer using Layer.succeed and Layer.unwrap, though I need to think through the conventions around Layer.succeed calling runtime-backed APIs. The webSocketConstructorLayer correctly uses Layer.succeed to provide the constructor function itself rather than calling imperative APIs at layer construction time, with the async loading deferred to Effect.promise inside Layer.unwrap. All the imports follow the namespace convention properly, and I'm not finding any actual violations of the Effect service conventions here. Looking at the three touched TypeScript files—the test, the native module adapter, and the runtime layer—this appears to be a straightforward native module integration without any hidden dependencies or improper patterns. The test file is just a standard vitest test, nothing Effect-specific there. I need to reconcile the response format though: the check instructions say to respond with "All clear" exactly, but the system requires JSON output per the schema, so I should structure the response as valid JSON while conveying that no issues were found. This is just a plain adapter class, not an Effect service, so there are no convention violations here. The runtime.ts file handles the async loading correctly through Effect.promise inside Layer.unwrap, and the failure fallback stays properly in the layer. The modified files—runtime.ts with its proper namespace imports and layer composition, and nativeWebSocket.ts as a native adapter—both follow the expected patterns.