feat(mcp): update environment preferences#8728

The new ThreadDispatchLockV2 service exports its layer as threadDispatchLockLayer; the convention is a canonical export const layer for the module that owns a service (every other orchestration-v2 service module here does that, reserving suffixed names like layerMemory/layerWithLegacyImporter for alternative layers).

Suggested fix: move the tag plus its layer into a dedicated module (e.g. ThreadDispatchLock.ts) that exports layer, and consume it as a namespace at the six call sites (ThreadDispatchLock.ThreadDispatchLockV2, ThreadDispatchLock.layer). Renaming the export to layer in this file and importing * as KeyedSerialExecutor also satisfies the convention if you prefer to keep it colocated with the generic executor.

^{Posted via Macroscope — Effect Service Conventions}

Fixed at 1c6dee0730b. ThreadDispatchLockV2 remains in KeyedSerialExecutor.ts with the exact existing Context service key; the layer export is now the canonical layer and every service consumer uses the KeyedSerialExecutor module namespace. No second lock or renamed service identity was introduced.

mcp/EnvironmentPreferencesMcpService.test.ts:51

These two service modules are imported with renamed member aliases (layer as threadManagementLayer, layer as environmentMcpLayer, make as makeEnvironmentMcpService), which erases the module namespace at a service boundary. The convention here is a namespace import so the module's public shape stays visible (ThreadManagement.ThreadManagementService / ThreadManagement.layer, EnvironmentMcp.EnvironmentMcpService / EnvironmentMcp.make / EnvironmentMcp.layer) — the sibling EnvironmentMcpService.test.ts already avoids aliasing.

Suggested fix: switch to import * as ThreadManagement from "../orchestration-v2/ThreadManagementService.ts"; and import * as EnvironmentMcp from "./EnvironmentMcpService.ts";, then update the four usages in this file (threadLayer, the environmentMcpLayer.pipe(...) provide, makeEnvironmentMcpService.pipe(...), and the yield* EnvironmentMcpService / yield* ThreadManagementService acquisitions) to the namespaced members.

No longer relevant as of 1c6dee0730ba0a8399e9b5b3b488507e729b89e0

Fixed at 1c6dee0730b. The integration test now imports ThreadManagementService and EnvironmentMcpService as module namespaces and accesses each service, layer, and make member through that namespace.

🟢 Low internals/environment-mcp.md:35

The documentation incorrectly states that the mutation exposes only preset background profiles, so consumers are led to believe the supported custom BackgroundActivityProfile value cannot be selected. Mention custom alongside the presets.

No change is needed here. The update input intentionally uses BackgroundActivityProfile, whose only values are balanced, performance, and battery-saver (packages/contracts/src/settings.ts:629-634). custom belongs to the separate BackgroundActivityProfileSelection output/settings schema and requires timing overrides; this MCP surface deliberately does not accept arbitrary timing overrides. The current user and internal docs accurately describe the mutation boundary.