fix(grok): surface per-model reasoning effort in the composer - #5403

💭 I want to check the changed files for existing conventions, particularly GrokAcpSupport.ts, GrokProvider.ts, AcpSessionRuntime.ts, and GrokAdapter.ts.

1. browse_code — apps/server/src/provider/acp/GrokAcpSupport.ts

2. browse_code — apps/server/src/provider/Layers/GrokProvider.ts

💭 I note the pre-existing GrokProvider imports are untouched, so I move on to examining the actual changes in AcpSessionRuntime.ts and GrokAdapter.ts, keeping in mind the conventions around Effect service definitions, DI, errors, and layout as I assess whether this diff is mainly a feature change. Checking the interface change to pass reasoning effort through the session runtime service looks fine, as do the exported pure helper functions and the named imports in GrokAcpSupport.ts. I want to verify the test files use consolidated imports from effect and check how GrokAdapter.ts's changed lines and its test file handle fiber forking and test clock utilities.

3. browse_code — apps/server/src/provider/Layers/GrokAdapter.ts

4. browse_code — apps/server/src/provider/Layers/GrokAdapter.test.ts

💭 I'm checking AcpSessionRuntime.ts for issues, then reviewing the import structure in GrokProvider.test.ts and GrokAcpSupport.test.ts, along with the GrokTextGeneration.ts change, to verify consistent named imports from "effect" across the touched files.

5. browse_code — apps/server/src/provider/Layers/GrokProvider.test.ts

6. browse_code — apps/server/src/provider/acp/GrokAcpSupport.test.ts

💭 That looks fine. Now I want to check the AcpSessionRuntime changes and the GrokTextGeneration change, so I'm going to look at the relevant sections in AcpSessionRuntime around lines 220-240 and 790-810.

7. browse_code — apps/server/src/provider/acp/AcpSessionRuntime.ts

8. browse_code — apps/server/src/provider/acp/AcpSessionRuntime.ts

💭 I'm double-checking that the changes align with existing conventions—the GrokAdapterShape issue is pre-existing and untouched by this diff, and I don't see any usage of Layer.succeed or similar patterns that would need adjustment here. The new tests seem justified since they verify actual behavior changes rather than just proving a mechanical refactor, and the TestClock/forkChild usage looks fine. I'm concluding there are no real violations, though I need to reconcile the "All clear" instruction with the JSON response schema—I'll go with a JSON output where the title and summary both read "All clear" to satisfy both requirements. Let me also verify getProviderOptionStringSelectionValue and buildSelectOptionDescriptor usage line up correctly, though these seem more like implementation details than convention violations.