Fix quadratic thread-reopen replay: batch client apply + cap server resume gap - #4605

💭 I'm looking at the files that were modified to check for Effect service convention violations across the codebase, spanning server scripts, tests, WebSocket handling, React components, and performance utilities. Checking the imports in the new and modified files, I see they're consistently using namespace imports from Effect subpaths like import * as Effect from "effect/Effect" and similar patterns for Option, Queue, Ref, Stream, SubscriptionRef, and Semaphore. The React-focused files in the perf playground are mostly importing React utilities rather than Effect services, so those follow a different pattern. I'm partway through examining whether these changes introduce any convention violations or move things around in problematic ways. The EnvironmentSupervisor.EnvironmentSupervisor.of(...) pattern with the ["Service"] type annotation follows the correct convention, so that's good. Let me scan through a few of the actual files to make sure there aren't any other issues I'm missing. Looking at this performance-focused PR, I'm checking for any violations of the Effect service conventions. The threads.ts file properly uses namespace imports and keeps the batching logic within the existing service structure without introducing new error classes. The ws.ts changes are minimal—just adding a constant and some logic while correctly handling the OrchestrationGetSnapshotError with its cause field. The test utilities follow the convention with proper namespace imports and the EnvironmentSupervisor type annotation. The new package.json subpath export for thread-reducer is fine since it's exposing a pure reducer utility rather than a service definition. The imports in the perf playground and test files are straightforward named imports from these utilities, which is appropriate for non-service modules. Looking at the test-util imports from threads.ts, it's pulling in ThreadSnapshotLoader (a service tag) and helper functions through a barrel re-export. This is acceptable in a test harness context since the convention explicitly allows passing service instances in tests and integration scenarios. The real question is whether this PR introduces actual violations—it seems to be primarily performance work without problematic service boundary crossings. The harness correctly uses namespace imports for service modules like EnvironmentSupervisor, ConnectionWakeups, Persistence, and RpcSession, and properly leverages the ["Service"] type pattern when constructing service instances. But there's something else to check— the instructions say to respond "All clear" when there are no findings, yet the system requires JSON schema output, creating a conflict I need to resolve. The "All clear" instruction should go in the summary field, not replace the entire response. The JSON schema is mandatory, so I'll set the state to success with "All clear" as both the title and summary. I'm confident there are no Effect service convention violations in this performance PR.