fix(server): subscribe before provider settings watcher - #9271

💭 I'm checking whether the production code's use of subscribeChanges in ProviderInstanceRegistryHydration.ts actually matches what ServerSettingsService exposes, since the test only mocks streamChanges.

1. git_tools — subscribeChanges

2. git_tools — streamChanges

💭 I'm examining the test's lazy stream override on streamChanges, but noticing production code now calls subscribeChanges instead, which isn't overridden—so I need to check if the test still correctly verifies eager subscription behavior. I want to check the test file and mutable server settings helper for convention issues, like proper satisfies typing and correct namespace imports for Deferred.

3. browse_code — apps/server/src/provider/Layers/ProviderRegistry.test.ts

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

💭 I want to check whether the makeMutableServerSettingsService helper exposes subscribeChanges, so I'm looking at how it's defined in the test file.

5. git_tools — makeMutableServerSettingsService

6. browse_code — apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts

💭 I'm checking whether the pre-existing named import of ServerSettingsService violates the namespace-import convention for service boundaries, but since that line isn't part of the actual diff, I should only flag violations that are introduced or retained within the touched code itself. The test correctly uses namespaced imports and satisfies the Service shape, and mocking only streamChanges while leaving subscribeChanges untouched actually makes for a solid regression test — if the code ever reverted to the eager stream, it would miss the update and the test would catch it. Now I want to verify mutableServerSettings.subscribeChanges actually exists as expected. I need to check whether subscribeChanges requiring a Scope even matters inside Layer.effectDiscard — layer construction effects in this version of Effect may already run within a scope, so it could type-check without issue. I should verify how Layer.effect works in this repo's Effect version to confirm scoped effects are permitted there. I should verify whether Layer.effectDiscard actually provides Scope in this version, so I'll check the effect package version in package.json to confirm.

7. browse_code — apps/server/src/provider/Layers/ProviderRegistry.test.ts

8. git_tools — "effect":

💭 This looks like Effect v4, where Layer effects automatically get Scope in the environment. I'm examining how the test spreads the mock server settings object—since the spread evaluates the getters like streamChanges and subscribeChanges eagerly, only once, this could affect whether subscribeChanges returns a fresh value each time it's accessed. I'm checking whether the diff violates any conventions: no lint suppressions added, the test change is small and targeted rather than a large test added just to prove a mechanical refactor, and using Layer.succeed for the service instance is a reasonable test seam. The production change to use subscribeChanges is an improvement, though there's a stale doc comment elsewhere referencing streamChanges that isn't part of this diff, so it's a minor nit rather than a real issue. Now I'm wondering whether the declared layer type for ProviderInstanceRegistryHydrationLive still holds up given that Layer.effectDiscard and subscribeChanges require a Scope—since in Effect v4 the layer's own scope supplies that, Scope shouldn't leak into R, though the pre-existing type cast at the end could mask any mismatch anyway. I want to cross-check this against other places in the repo, like how DesktopTelemetryReceiver.ts and ProviderService.ts use subscribeChanges within their layer construction, to confirm this pattern typechecks elsewhere too.

9. git_tools — Layer.(effect|scoped|effectDiscard|scopedDiscard)

💭 I don't find any convention violations in the diff—both files look conformant. There's a tension between the instruction to respond exactly "All clear" when no findings exist and the requirement to output valid JSON, so I'll resolve it by producing JSON with the title/summary fields set to "All clear".