Add reusable loopback development auth - #4360

💭 Looking at the diff to see how it aligns with Effect service conventions. I'm checking the new files and service-related changes, starting with the pure helper functions in the network host file, then examining the error classes in the config file that use Schema.TaggedErrorClass. The error classes are validation/domain errors created without underlying failures, so they don't need causes—just messages derived from their attributes. The imports look good too: pure helper functions like isLoopbackAddress, isLoopbackHost, and isWildcardHost are imported as named imports from the shared package, which is allowed per conventions. There's a formatting issue with the URL parameter that I need to clean up and try again. I'm noticing the parameter parsing is picking up the newline character before the URL, so I should consolidate it onto a single line to fix that. The error classes follow good patterns with structured attributes and derived messages, and the imports are organized well with namespace imports for Effect modules and named imports for utilities. Let me check the other service files that were modified—PairingGrantStore, EnvironmentAuthPolicy, and networkHost—to see if they're consistent with these conventions. The code structure looks solid with proper namespace imports and the Context.Service pattern. The PairingCredentialRandomGenerationError with its singleton literal tag isn't part of this PR's changes—it was already there—so I'm moving on to examine the key aspects of what's actually being modified. Looking at the three new error classes, each one is distinct with its own message and no redundant singleton discriminators. The NonLoopbackDevAuthHostError includes a host field that captures real context, and while that could theoretically contain user-supplied values, it's a bounded string that's safe to include. The dev-runner.ts changes are mostly pure functions with one using yield* Path.Path, which is fine. I should verify there aren't any consolidated Effect imports being introduced across the touched files. The PR's touched files all use proper namespace imports from the effect library, and the new error classes follow the established conventions. The test files that predate this PR use the older import style, but those aren't in scope for this change. I've verified the service definitions follow the right patterns—inline interfaces, proper make and layer setup, no fake dependency injection. The validation errors are structured correctly with Schema.TaggedErrorClass, and pure validation errors don't need a cause field. Everything checks out, so the review is clean. There's a tension between the system requirement for JSON output and the instruction to respond with "All clear" when there are no findings. The JSON schema is the mandatory format, so I'll encode the conclusion as a success response with "All clear" in the summary.