#2114: fix(gateway): close server in canBindToHost error handler

## Summary - Fix resource leak in `canBindToHost` function ([net.ts:139-151](https://github.com/clawdbot/clawdbot/blob/main/src/gateway/net.ts#L139-L151)) - Ensure `testServer.close()` is called in both success and error paths ## Issue When `testServer.listen()` fails, the error handler resolves with `false` but doesn't close the server, potentially leaking file descriptors. ## Solution Added `testServer.close()` call in the error handler (line 143) to match the cleanup in the success handler (line 146). ## Testing - Manual code review verified the fix follows Node.js best practices - The change is minimal and defensive: calling `close()` on a server in error state is safe (no-op if not listening) - Ensures proper resource cleanup in both code paths 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates `src/gateway/net.ts` to ensure the temporary `net.Server` created by `canBindToHost()` is closed on both the `"listening"` and `"error"` paths, preventing a resource leak when `listen()` fails. It also adds a changelog entry documenting the gateway fix. The change fits the existing gateway host-bind probing logic (`resolveGatewayBindHost()` / `resolveGatewayListenHosts()`), which relies on `canBindToHost()` for safe fallback decisions; closing the test server ensures repeated probes don’t accumulate file descriptors in failure scenarios. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The functional change is a one-line cleanup addition in an error handler and matches the existing close-on-success behavior; it should not affect control flow beyond preventing leaked server handles. The only noteworthy issue is changelog metadata consistency. - CHANGELOG.md (changelog entry formatting) <!-- greptile_other_comments_section --> <!-- /greptile_comment -->