GHSA-ppx3-28rw-8fpf

### Summary The fix for CVE-2026-44661 (commit `5b16e43`) added the `ensure_secure_url()` / `is_secure_url()` helpers and wired them into the three HTTP-family plugins, but it did not reach the GraphQL or WebSocket plugins. The GraphQL plugin (`utcp-gql`) still uses the `startswith` prefix check that the fix explicitly replaced, so `http://127.0.0.1.attacker.example` and `http://localhost.evil.com` pass it. The WebSocket plugin (`utcp-websocket`) performs no URL validation at all, even though its own docstrings state it enforces "WSS or localhost only." Both plugins reach the same SSRF that CVE-2026-44661 was filed for, and because both attach the call template's configured auth headers to the outbound connection, the SSRF can also leak API keys and OAuth tokens to an attacker-controlled host. ### Details In the CVE-2026-44661 fix (commit `5b16e43` ("fix(http): block SSRF via attacker-controlled OpenAPI servers[0].url")), two things in it pointed at sibling issues. The commit message says the change is "replacing the duplicated prefix check", and the new `utcp_http/_security.py` docstring names the exact bug: > URLs whose hostname *starts* with `localhost` / `127.0.0.1` but isn't actually loopback (e.g. `http://localhost.evil.com`, `http://127.0.0.1.attacker.example`). The earlier `startswith` check let these through. The word "duplicated" says the vulnerable check existed in more than one place. The fix only updated the three HTTP-family plugins (`http`, `streamable_http`, `sse`). The other communication-protocol plugins were also inspected. **GraphQL plugin (`utcp-gql`).** `plugins/communication_protocols/gql/src/utcp_gql/gql_communication_protocol.py` still has the pre-fix check at line 43: ```python def _enforce_https_or_localhost(self, url: str) -> None: if not ( url.startswith("https://") or url.startswith("http://localhost") or url.startswith("http://127.0.0.1") ): raise ValueError("Security error: URL must use H