fix: reconnect faster after remote server updates - #5404

💭 I need to review the changed files to understand what's happening. The nudgeReconnectDuringUpdateRestart function in server.ts looks like a helper rather than a service, so I should verify the Duration import is properly namespaced. The test file is using Stream utilities like fromIterable, and I need to confirm that SERVER_UPDATE_RESUME_TIMEOUT is defined and that the server.ts diff is complete. I'm checking the conventions for this PR—it doesn't create or refactor a service, and the imports look correct with namespace imports from effect subpaths. I need to verify the TestClock import path matches what other tests use in this repo. The test correctly uses Effect.forkChild with { startImmediately: true }, but there's a potential type mismatch where nudgeReconnectDuringUpdateRestart returns Effect.Effect<void> while something else expects a different type. Looking at the timeout change—it was previously Duration.seconds(30) but now uses SERVER_UPDATE_RESUME_TIMEOUT set to 4 minutes. That's a behavior change, though tests do exist for it. The real question is whether this violates Effect service conventions, so I'm examining the test file's import patterns more carefully. Looking at this from the Effect service conventions angle, this PR isn't really a service refactor—it's extracting a helper function that takes stateChanges stream and retryNow effect as parameters. The question is whether that counts as "service injection" under the convention that flags factories accepting service implementations. The nudgeReconnectDuringUpdateRestart function does accept an object with these dependencies derived from the environment, so I need to think through whether that fits the pattern. The caller already has environmentRegistry in scope, and the extracted helper is testable with these per-environment bound operations as parameters rather than the service itself. I think this works as a deliberate callback strategy and test seam—it's a pure helper in the state module, not a service definition. The optional interval parameter with a Duration default is fine too. Now I should verify the TestClock import path is valid for this repo's Effect version and check how other test files handle imports. The changes follow conventions well—no new services, consolidated imports, or runtime modifications. One thing to verify is whether Effect.forkChild works correctly inside a test using TestClock. The stateChanges stream type is a bit loose compared to the registry's actual state type, but that's a minor style consideration. For the callback pattern with retryNow and stateChanges as pre-bound values: these aren't methods but values passed as test seams in a state module, which aligns with the convention's allowance for deliberate callback strategies. No flags needed there. The review comes back clean, so I'm formatting the response as a success with "All clear" as the summary.