🐛 Bug Report — Runtime APIs: fetch requests to external endpoints without the X25519MLKEM768 key group raise 525 errors, connect() works fine

On a Worker deployed to a Custom Domain, `fetch()` fails with HTTP 525 to certain origins. In the same request, to the same host, `connect(..., {secureTransport: "on"})` completes a TLS handshake and returns a valid HTTP response. But a byte-identical script on *.workers.dev returns 200 just fine.

```js
await fetch("https://github.com/") // throws HTTP 525
await connect({hostname:"github.com",port:443}, {secureTransport:"on"}) // returns 200
```

Now I realise the outbound path for fetch requests on the edge likely lives outside this repo. I'm filing here because it's the only public tracker for the Workers runtime, this definitely occurs somewhere at runtime, and because I'm on a free plan and don't have any other way to report an actual bug.

### What I tried

Across several third-party origins I tested, fetch returns 525 if the origin does not support the `X25519MLKEM768` key agreement group:

| origin | X25519MLKEM768 supported | from workers.dev | from custom domain |
| --- | --- | --- | --- |
| pypi.org, aws.amazon.com, www.sanity.io | yes | 200 | 200 |
| github.com, api.stripe.com, sentry.io | **no** | 200 | **525** |
| api.sanity.io, cdn.sanity.io | **no** | 200 | **525** |
| raw.githubusercontent.com | yes | 200 | **525** |

My zone has `cache/origin_post_quantum_encryption = supported`, which per [the docs](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-to-origin/) affects *"all outbound connections from the zone […] including fetch() requests made by Workers on your zone"*. However I did try setting it to off, which didn't solve it either.

### Conclusion

I assume there is some bug in the TLS handshake process that you introduced when enabling the post-quantum hardening, causing connections to origins without matching PQ key agreement groups to fail.
I appreciate the push for security, but would prefer to be able to make outbound requests to less secure origins.

### Environment

- wrangler 4.123.0
- Compatibility Date: 2026-08-15
- no compat flags
- placement.mode: "off"
- colo FRA
- Zone has TLS set to full, Min TLS 1.0, and no Worker routes.

Failing rays (all FRA):
- `a2cfb2030d7fdc6a`
- `a2cfb204ff19dc6a`
- `a2cfb2053f6ddc6a`
- `a2cfb2059fcedc6a`

No repository file, test, or entry point is named; begin by tracing whether outbound fetch TLS handling exists in workerd and compare it with the working connect() path. Reproduce the 525 behavior with the listed origins and post-quantum settings; done means identifying the responsible component and, if it is in this repository, adding coverage for the failing handshake path.

Written by the indexing model from the issue text.