#21265: Security/Pairing: reject insecure non-loopback ws setup URLs

## Summary - reject setup-code generation when the resolved gateway URL is `ws://` on a non-loopback host - keep loopback `ws://` support for local development - add regression tests for rejected insecure remote URLs and allowed loopback URLs - update existing pairing tests to use TLS where required by the new guard ## Why Pairing setup payloads include gateway credentials. Allowing plaintext non-loopback WebSocket URLs can expose those credentials in transit. ## Testing - `pnpm test src/pairing/setup-code.test.ts` <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds transport security validation to pairing setup, rejecting plaintext `ws://` connections to non-loopback hosts while preserving local development workflows. The implementation uses loopback detection covering standard patterns (`localhost`, `127.*`, `::1`, `::ffff:127.*`) and validates URLs before setup code generation. - Implemented `isLoopbackHost()` helper to identify loopback addresses - Added `validateTransportSecurity()` to enforce `wss://` for remote hosts - Updated existing tests to use TLS where required by the new validation - Added regression tests for both rejected insecure URLs and allowed loopback cases <h3>Confidence Score: 4/5</h3> - This security improvement is safe to merge with minor edge cases to consider - The PR correctly implements transport security validation to prevent credential exposure over plaintext connections. The implementation has good test coverage and updates existing tests appropriately. One minor consideration is IPv6 loopback variant handling, but the current implementation covers standard cases. The security benefit significantly outweighs the small risk of edge case scenarios. - No files require special attention - the implementation is straightforward and well-tested _{Last reviewed commit: cd4268c} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->